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ABSTRACT 


This thesis presents the simulation results and performance analysis of IEEE 
802.15.4 in an oceanic environment. The 802.15.4 standard allows simple sensors 
and actuators to co-exist in a single wireless platform. The simulation is performed 
using Network Simulator, version 2 (NS2) which is an open-source network 
simulator tool. NS2 is an event driven network simulator developed at DC Berkeley 
that simulates a variety of networks. Leveraging on the capabilities of NS2, the 
performance of the IEEE 802.15.4 protocol has been studied based on variations in 
node density, mobility as well as loading conditions. The mobility model selected for 
the simulation has considered the ocean effects on the mobile nodes, in particular 
the surface current. However, the available mobility models (Random Waypoint, 
Gauss-Markov, Manhattan Grid and Reference Point Group) do not represent the 
real life mobility in an oceanic environment scenario. As a result, actual data of 
surface measurement in the Monterey bay area is used to generate the node 
movements. The results from this analysis provide insights into the performance of 
IEEE 802.15.4 and its suitability for operating in an oceanic environment. 
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I. INTRODUCTION 


A. GENERAL 

Mobile Ad-hoc NETworks (MANETs) advocate self-configuration and 
adaptation of wireless links between communication devices (mobile nodes) that 
operate autonomously or as an extension to a wired infrastructure. The wireless 
communication links that form the network have to be characterized by a 
dynamic topology with no fixed infrastructure since the nodes are highly mobile. 
The nodes are equipped with antennas for reception and transmission within the 
communication medium through broadcasting. These nodes within MANETs 
have salient properties including limited power, relatively short communication 
distance, low processing power and limited bandwidth. 


Advancements in sensor technology have made MANETs a viable solution for 
many commercial as well as military applications. But there has been relatively 
limited focus on using MANETs in an ocean environment. A typical scenario 
would consist of a collection of nodes, which are ocean buoys containing sensors 
that are partially submerged at various positions within a designated operating 
area. These nodes would be at various depths and will be drifting slowly towards 
as well as apart from each other. An example military application of such a 
system in an ocean environment would be for quick deployment for early warning 
defense. Wireless networks and large-scale sensors provide information and 
sensing dominance for network centric warfare. Such a system needs to be 
robust for frequent and unpredictable changes in topology due to the mobility of 
ocean buoys. It also has to be able to handle large variations in information load 
with the possibility of information transfer being multi-hopped without centralized 
control. 


1 



B. MOTIVATION 


Conventional protocols waste energy in collisions and idle listening. IEEE 
802.15.4 is a standard that has been designed for low data rate, low power 
consumption and low cost which is ideal for MANET applications. There are a 
host of technical difficulties for implementing this technology for oceanic 
applications. An oceanic system creates a challenging environment where the 
ocean current and waves are dynamic and unpredictable which is highly variable 
as a function of time and space. These factors would cause interference and bit 
errors at the physical level resulting in unreliable and intermittent connectivity and 
hence hinder the scalability of protocols. This study focuses on performing the 
necessary theoretical research to conduct analysis of the performance of IEEE 
802.15.4 in an ocean environment using an open-source network simulator tool. 

C. OBJECTIVE AND SCOPE 

The objective of this thesis is to perform the necessary research to 
conduct analysis on the performance of IEEE 802.15.4 in an oceanic 
environment using an open-source tool called network simulator, version 2 
(NS2). A simulation model will be built and the various performance behaviors 
will be investigated that are relevant to a generic wireless networks (such as 
packet delivery ratio, delivery latency, control overhead and transmission 
collision) as well as behaviors that are specific to MANETs (such as association, 
orphaning and transmission methods). 

The experiments for performance analysis are simulated using the latest version 
of NS2 2.29 [1]. NS2 is a discrete event simulator that is targeted for networking 
research purposes. It provides substantial support for simulation of protocols 
over wired and wireless networks. In this thesis, besides the installation of NS2, 
an IEEE 802.15.4 extension [2] (contributed code) will be utilized. This code 
conforms to IEEE P802.15.4/a18 draft based on the physical layer and the MAC 
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layer behavior of a wireless network. For the performance analysis, an 
appropriate mobility model representing the oceanic environment has to be 
selected. In essence, this thesis endeavors to answer the following questions: 

1. Are the available mobility models in NS2 suitable to simulate the ocean 
environment? Currently there are several models that have been used for 
research investigation. A few of the models considered are Random 
Waypoint, Gauss-Markov, Manhattan Grid and Reference Point Group 
mobility model. Each of these models will be examined in details for 
suitability to represent node movement in an ocean. If it is determined that 
these models are not suitable, what are good alternatives to simulate the 
ocean mobility model? 

2. With the selected mobility model, how does IEEE 802.15.4 perform in the 
oceanic environment? Simulations will be conducted using NS2 and 
evaluated against a set of performance metrics. 

D. THESIS OUTLINE 


This chapter provides the introduction and motivation to the study of IEEE 
802.15.4 protocol. Chapter II introduces the theoretical background to this 
research. An overview of IEEE 802.15.4 as well as key concepts behind the 
ocean effects on mobile nodes is presented. Also, mobility models that are 
specific to the simulation are discussed. These mobility models are broadly 
classified as independent or group-based. Chapter III will specifically focus on 
the methodology in computing node movements from measured data of the 
Monterey bay. The computed movement will be used to generate the scenario 
file in NS2. Chapter IV is dedicated to the simulation environment and setup with 
Chapter V discussing the results of the simulation. Finally, Chapter VI will 
conclude these studies and recommend further actions and propose future 
studies. 
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II. THEORETICAL BACKGROUND 


This chapter provides an introduction to IEEE 802.15.4 as well as key 
concepts and theory relating to this research. The various mobility models used 
in simulating the MANET are discussed. Since the mobility models are 
determined by the environment, factors that contribute to the movement of nodes 
are studied, especially the ocean surface. These ocean effects are taken into 
consideration for the selection of mobility models, if applicable. Finally, the 
performance matrices used in the evaluation of IEEE 802.15.4 for ocean 
environment are detailed. 

A. IEEE 802.15.4 

The technology for wireless communications has made tremendous 
advances, in which most attention has been given to wireless local area networks 
(WLANs) and technologies involving the IEEE 802.11 standard. While IEEE 
802.11 standard focuses on high-end wireless communication system, the IEEE 
802.15.4 standard is designed for low cost, low power applications with less 
stringent requirements on throughput and latency (see Figure 1). The primary 
objective is to provide reliable data transfer with reasonable battery life for short 
range operations while maintaining simple and flexible protocol. 


n 0bp«i 



Figure 1 - Wireless Networking (from ref. [3]) 
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1. 


OVERVIEW OF IEEE 802.15.4 


The IEEE 802.15.4 standard defines the physical layer (PHY) and medium 
access control (MAC) sub-layer specifications for Low Rate - Wireless Personal 
Area Networks (LR-WPANs). Currently, the development of the upper layers is 
led by the ZigBee™ Alliance through definition of application profiles utilizing the 
simplified five layer ISO/OSI reference model shown in Figure 2. The IEEE 
standards board approved the IEEE P802.15.4B (D6) Draft Revision [4] in June 
of 2006, which defines the detailed specifications. Unlike WLANs having higher 
operating range and data-rate, WPANs are designed to function in a personal 
operating space which can be extended up to 10m omni-directional. Within a LR- 
WPAN, a device can be assigned to either a 16 bit short or a 64 bit extended 
address during association. Hence, a single network could potentially 
accommodate 65,536 (2^®) devices. 
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Figure 2 - ISO-OSI Reference Model and IEEE 802 Model (from ref. [6]) 


Some of the unique characteristics of a LR-WPAN are: 

• Over-the-air data rates of 250 kb/s, 40 kb/s and 20 kb/s. 

• Star or peer to peer operation. 

• Allocated 16 bit short or 64 bits extended addresses. 

• Allocation of guaranteed time sots (GTSs). 

• Carrier sense multiple access with collision avoidance (CSMA-CA). 

• Full acknowledgement protocol for transfer reliability. 

• Low power consumption. 
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• Energy detection (ED). 

• Link quality indication (LQI). 

• 16 channels in the 2450 MHz band, 10 channels in the 915 MHz 
band and 1 channel in the 868 MHz band. 

The following sections highlight some important design features [4, 5 & 6] of this 
standard. 

2. Network Topologies and Device Architecture 


Devices that participate in a LR-WPAN can be of 2 types, a full function 
device (FED) or a reduced function device (RFD). Each RFD can only associate 
with a single FFD at an instance whereas FFDs can communicate with other 
FFDs or RFDs. A FFD contains the complete set of MAC services and is able to 
operate as a network coordinator or a network device. On the contrary, a RFD is 
simply a network device with a reduced set of MAC services and usually used for 
simple applications. Three types of topologies are supported, namely star, peer- 
peer and cluster tree as shown in Figure 3. The decision on which topology to 
adopt is dependant on the operating distance, typically one-hop star and multi¬ 
hop peer-to-peer or cluster tree topology when communication range exceeds 
10m. 


star Topology Network 




Cluster Network 



^ Full Function Device 


Figure 3 - IEEE 802.15.4 Network Topologies (from ref. [6]) 
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With star topology, communication is established between devices by a single 
central controller known as the PAN coordinator. The PAN coordinator (which is 
a FFD) acts as a hub that forms direct links to other devices. These devices, 
consisting of FFDs or RFDs, form around the PAN coordinator and act as data 
terminal locations. In the peer-to-peer topology, each device in the network can 
communicate with any devices within its radio range. Although a PAN coordinator 
is required somewhere in the network, each device can form multiple links to 
other devices, hence increasing redundancy at the expense of complexity. The 
cluster tree is similar except that the network hierarchy is more complex. This 
topology simplifies routing and reduces direct links at the expense of data traffic 
latency. 


The architecture of a LR-WPAN device, shown in figure 4, comprises the PFIY 
layer and MAC sub-layer. The PHY layer consists of an RF transceiver including 
a low level control mechanism while the MAC sub-layer provisions for access to 
the physical channel for all transfer types. Through the service specific 
convergence sub-layer (SSCS) an IEEE 802.2 logical link control (LLC) can 
accesses the MAC sub-layer. Each layer will contain services which have the 
capability to build functions on the services of lower layers and present them to 
the next higher layer. Every event will require passing of service primitives from 
a layer to another through a service access point. There are 14 PHY and 35 
MAC primitives described in IEEE 802.15.4. 



Figure 4 - LR-WPAN Device Architecture (from ref. [6]) 
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Functional Features 


In the IEEE 802.15.4 standard, some of the functional features used are 
the superframe structure, different data transmission methods, low power 
consumption as well as self-configuration and orphaning. 

• Superframe structure. The superframe (shown in Figure 5) is a 
special network communication architecture introduced for time division 
multiplexing. The superframe consists of an active and an inactive period 
where beacons in a beacon-enabled network are periodically transmitted 
for synchronization. Within the active portion, devices in the network can 
transmit with slotted Carrier Sense Multiple Access - Collision Avoidance 
(CSMA-CA) in the contention access period (CAP). In the contention free 
period, only devices with a guaranteed time slot (GTS) can perform data 
transmission. In CSMA-CA, transmitting devices will listen to the channel 
for a predetermined time to check for activities on the channel. If the 
channel is idle, the device is permitted to transmit and if busy, the station 
has to delay its transmission. 

CAP CFP Beacon 




GTS 

GTS 

Inactive Period 


1 2|3|4 

fi|fi 

7 

8 

8 

10 11 |12 

13|l4|l5 



Active Period 


Figure 5 - A Typical Superframe Structure (from ref. [3]) 

• Data transmission methods. Data transfer can occur either from a 
device to a coordinator, coordinator to a device or from one peer to 
another in a peer-to-peer multi-hop network. In general, the data transfer 
process can be classified into direct transmission, indirect transmission 
and GTS transmission. Direct data transmission will happen for the three 
data transfer cases and depending on whether the network is beacon- 
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enabled or beaconless, a slotted or unslotted CSMA-CA is used. Indirect 
data transmission applies only to data transfer from a coordinator to its 
devices where the coordinator keeps a data frame in a transaction list and 
waits for the device to extract data. Devices will check on beacon frames 
received from the coordinator to determine if data packets are pending in 
the transaction list. Also, it is possible, but unlikely that indirect data 
transmission occurs in beaconless mode where unslotted or slotted 
CSMA-CA is used in the data extraction procedure. Finally, GTS data 
transfer occurs both from a device to its coordinator and from coordinator 
to devices. GTS transmission does not require the use of CSMA-CA 
protocol. 

• Power Consumption. Due to their mobile nature, devices are 
usually battery operated and hence power consumption is a vital factor. 
Several power-saving mechanisms are incorporated in IEEE 802.15.4 to 
prolong device battery life. Most of these mechanisms operate in beacon 
enabled mode where the receiver of coordinator or its devices are 
disabled for a specific period during direct transmission. Devices can also 
be configured to low power (i.e. sleep) state when there is no data 
transmission or transmitting GTS data transfer at low duty cycle. Other 
inherent properties to reduce power consumption are the small CSMA-CA 
back-off period and short transceiver warm-up time. 

• Self-configuration and Orphaning. The self-configuration capability 
is part of the association and disassociation functions in the MAC sub¬ 
layer. This capability will automatically establish a star network and also 
perform self configuration of peer-to-peer network. Orphaning mechanism 
provides detection of link or node failures for devices in beacon-enable 
mode and is tracking beacons. When a device misses a pre-determined 
number of beacons consecutively, the device will perform a re-alignment 
procedure to establish link with its coordinator. 
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PHY Layer 


One of the primary reasons for the failure of several proprietary 
technologies is the inability to adapt. However, IEEE 802.15.4 has been 
designed to be applied worldwide supporting three different operating frequency 
bands, with a different number of supporting channels and at specific data rates 
(Table 1). 


Frequency band 

# of channels 

Data rate (Kbps) 

Applicability 

Restrictions 

2.4 GHz 

16 

250 

Woridwide 

Uniicensed 

915 MHz 

10 

40 

USA 

Licensed 

868 MHz 

1 

20 

Europe 

Licensed 


Table 1. IEEE 802.15.4 Operating Frequencies. 


There are 2 types of frequency bands defined in the PHY layer, the license-free 
industrial scientific medical (ISM) 2.4 GHz band and the licensed 868/915 MHz 
band. In total, there 27 channels and 3 different data-rates that is specific to the 
frequency band. The availability of the ISM band eliminates the need for a 
license and allows development of devices to be used anywhere in the world. 
With that, investment risk is greatly reduced which results in lower cost devices. 
Despite its simplicity, IEEE 802.15.4 also strives to provide flexibility which allows 
selection of operating in any one of the channels. The basis for the selection is 
usually dependent on availability, congestion state and data rate of each channel 
(in terms energy and cost efficiency). 

The PHY layer acts as the interface between the MAC sub-layer and the physical 
medium and provides both data services and management services accessed 
through two service access points. The following tasks are the responsibility of 
the PHY layer. 

• Activation and deactivation of radio transceiver . Depending on the 
requests from the MAC sub-layer, the internal operating state of the 
transceiver can be de-activated (sleep mode), transmitting or receiving. 
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• Energy detection (ED) within the current channel . This service 
performs the estimation of the received power within the channel 
bandwidth and this result can be used in the network layer for channel 
selection or for the purpose of clear channel assessment (CCA). 

• Link quality indication (LQI) for received packets . This 
measurement is derived from receiver ED estimates, signal-to-noise ratio, 
or both measures to compute the link quality or strength where packets 
are received. The result of this measure is used in the network or 
application layer. 

• Clear channel assessment (CCA) for CSMA-CA . CCA is performed 
by the PHY layer using at least one of three modes of energy, carrier 
sense and carrier sense with energy. In energy mode, a medium is 
reported busy if any detected energy is above the ED threshold. As for 
carrier sense mode, a medium is reported busy when the detected signal 
has the modulation and spreading characteristics of IEEE 802.15.4. The 
last mode will report a busy medium when both above-mentioned 
conditions are met. 

• Channel frequency selection . Upon receiving request from MAC 
sub-layer, the PHY layer will tune to the selected channel. 

• Data transmission and reception . This is the primary task of the 
PHY layer where various modulation and spreading techniques are 
employed depending on the frequency band. 

5. MAC Sub-layer 

The MAC sub-layer acts as the interface between the SSCS and the PHY 
layer, providing MAC data and management services. The features of MAC sub¬ 
layer includes beacon, network configuration, channel access, guaranteed time 
slot (GTS) and link management. The following tasks are the responsibility of the 
MAC layer. 
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• Beacon generation for PAN coordinator and synchronization . A 
FFD that is designated as a coordinator has the ability to operate in 
beaconless or beacon-enabled mode. Beacon-enabled mode allows the 
use of superframe that has a structure which is bounded by network 
beacons and is divided 16 equal sized slots. Beacons are transmitted 
periodically for describing the superframe structure, synchronization of 
attached device and identifying the network. Synchronization is required 
for data polling, energy saving and detection of orphaning. 

• Association and disassociation of network . MAC sub-layer 
association and disassociation supports the automatic setup and self¬ 
configuration of star and peer-to-peer network. 

• Employing CSMA-CA mechanism for channel access . In 
consideration of the low data rate in LR-WPAN, the request-to-send (RTS) 
and clear-to-send (CTS) mechanism are not utilized in the CSMA-CA. 

• Allocation and management of guaranteed time slot (GTS) 
mechanism . While in beacon-enabled mode, GTS allows allocation of 
dedicated resource to a particular device within a certain portion of the 
superframe. 

• Maintain reliable link between two MAC sub-layer entities . Various 
mechanisms such as CSMA-CA, CRC data verification, frame 
acknowledgement and retransmission, are employed by the MAC layer to 
provision for reliable link. 

B. MOBILE AD HOC ROUTING PROTOCOLS 

Due to the highly dynamic nature of mobile nodes and the absence of a 
central controller, traditional routing protocols used for a wired network cannot be 
applied directly to a MANET. Some of the considerations required in the design 
of MANET routing protocols include the mobility of nodes, unstable channel 
states and resource constraints such as power and bandwidth. In a MANET, the 
movement of nodes will cause communication between nodes to be disrupted 
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from frequent path breaks and reconnections. Also, the broadcasting of radio 
channels can be highly unstable and the network layer has to interact with the 
MAC layer for available channels. In addition, power availability is often limited 
since the nodes are connected to batteries. Currently, the network and upper 
layers of IEEE 802.15.4 is being implemented by the ZigBee Alliance. Details of 
Zigbee Routing protocols will be discussed and other ad hoc routing protocols 
will not be addressed in this thesis. 

1. Zigbee Routing Protocols 

The MAC and PHY layers of IEEE 802.15.4 have no notion of node 
resources and energy. At the network layer, Zigbee supports node activation, 
network discovery, network formation and routing of packets. Similar to IEEE 
802.15.4, Zigbee is an industrial standard that is targeted for low data rate, low 
power consumption, low cost as well as long life wireless network operations. 
Zigbee employs a basic master-slave configuration where each master can 
support up to 254 slaves that can be nested to support a hierarchical routing 
strategy [7]. In addition, Zigbee provides a unique feature of redundancy in 
communication hence eliminating single point of failure in mesh networks. The 
routing algorithms defined for use by Zigbee are the Ad Hoc On Demand 
Distance Vector (AODV) protocol and the Cluster Tree protocol. Detailed 
Documentation for these two protocols is provided in the Zigbee specification [8]. 

2. Ad Hoc On Demand Distance Vector (AODV) Protocol 

The AODV is a pure on-demand acquisition algorithm system that allows 
message passing through neighboring nodes to nodes that are unreachable [9 & 
10]. Routing is accomplished by discovering the shortest possible route and 
ensuring that these routes do not contain loops. AODV also has the ability to 
adapt to route changes and can create new routes when error occurs. Individual 
mobile nodes operate as a special router where routes are obtained only when 
required with minimal reliance on periodic updates. Nodes not within the active 
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paths neither maintain any routing information nor participate in exchanging 
routing tables. However, a route needs to be discovered or maintained when 
there is communication between two nodes or that the nodes are in the direct 
path between the source and destination nodes. In essence, AODV seeks to 
minimize the number of control messages sent. 

There are several techniques employed for a mobile node to be aware of other 
nodes in its vicinity, and one such technique is local broadcasting of “hello” 
messages. Routing tables of the neighboring nodes are organized to have 
optimized response time for local movements and establishing request of new 
routes. The primary objectives of the algorithm are [6]: 

• Broadcast discovery packets when necessary 

• Distinguish between local connectivity management and general 
topology maintenance. 

• Disseminate to neighboring mobile nodes that are likely to need the 
information about changes in local connectivity. 

For the instance where a destination or intermediate node has no routing 
information, the Path Discovery process is initiated. Each node keeps track of 
neighboring nodes by listening for the “hello” messages that each node 
broadcasts at set intervals and by also maintaining two separate counters, the 
sequence number and broadcast id. The process begins with the source node 
initiating route request (RREQ) packets to the neighboring nodes. The source 
address and broadcast id will uniquely identify the RREQ. The broadcast id is 
incremented for a new RREQ. When an intermediate node receives a RREQ, it 
increases the hop count and rebroadcasts the RREQ to other neighboring nodes. 
If that particular node has received a similar RREQ, the redundant RREQ will be 
dropped. Along the path from the source to destination node, a reverse path is 
automatically set up where every node maintains the record of the neighboring 
node that sends the broadcast. 
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In summary, the route to the destination is determined by comparing both 
destination sequence number in the node’s route entry and the RREQ. The node 
will respond by either rebroadcasts of the RREQ or unicasts a route reply 
(RREP) packet back to the node in which request is received. When the RREP 
packet routes back to the source, a forward pointer is established on each node 
and timeout information is updated. This process will establish a uni-directional 
route and is repeated in the reverse direction for a bi-directional route. Due to 
movement of nodes, there could be errors during routing of messages. A route 
error message (RERR) allows nodes to adjust routes by removing all routes 
containing bad nodes from the routing table. This specification is detailed in RFC 
3561 [11]. The path discovery process, forward and reverse path are shown in 
Figure 6. 


Destination q 
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Figure 6 - Path Discovery, Forward and Reverse Path (from ref. [10]) 


3. Cluster Tree Protocol 


The Cluster Tree Protocol utilizes link-state packets to form a single 
cluster network or a potentially large cluster tree network. The network is mainly 
self-organized and network redundancy is maintained to achieve a high degree 
of fault resistance and self-repair. Essentially, nodes form a cluster during the 
self-organizing process and these formed clusters will connect to each other. 
Within a cluster of nodes, a cluster head is selected which will assign a unique 
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node ID to each individual node member during the cluster formation process. 
The connection between clusters is established using the Designated Device 
(DD) which assigns a unique cluster ID to each cluster. Basically, the DD is a 
node having high computing ability and large memory space. A typical cluster 
tree network is shown in Figure 7. Below sub-section details the process for 
single and multi cluster network. 



Figure 7 - Typical Cluster Tree Network 

a. Single Cluster Network 

The process of cluster formation begins with the selection of cluster 
head, followed by the cluster head expanding links to other node members 
forming a cluster. There are several ways to select the cluster head, based on 
the initiating node or stored parameters. When a particular node is activated, 
that node will listen for “hello” messages (i.e. beacons in the IEEE 802.15.4 MAC 
layer) from other nodes. After a certain duration when no messages are received, 
the node appoints itself as the cluster head and sends out “hello” messages. If no 
connection request is received, the node reverts to its original status. For the 
other option, the selection is determined from stored parameters such as 
transmission range, power capacity, computing information or location 
information. 

As the cluster head, the node will periodically broadcast “hello” messages which 
consist of a partial MAC address and node ID 0. Neighboring nodes will send a 
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“connection request” message upon receiving the “hello” message. The cluster 
head node will in turn reply with a “connection response” message containing the 
node ID and the respective node member will acknowledge the receipt of 
message. Due to the dynamic mobile nature, all member nodes within the 
transmission range of cluster head have a star topology with one hop. This 
cluster can also expand to a multi-hop structure with each node having multiple 
connections. For the instance where all node IDs have been used or other limits 
have been reached, connection requests will be rejected by assigning a unique 
node ID. Also, if no update is received from a member node, it is eliminated from 
the cluster. 

It is possible for a node to receive a “hello” message from another cluster. The 
receiving node will include the cluster ID (CID) of the transmitting node and will 
update the cluster head through a link state report. This process allows the 
cluster head to be aware of the entire topology for better optimization. If there is a 
need to change the topology, the cluster head will send a “topology update” 
message. In addition, the periodic “link state report” message is used to indicate 
the presence of a troubled node. A cluster head in trouble will result in stoppage 
of the “hello” messages and member nodes will be re-configured. 

b. Multi-Cluster Network 

A network having multi-clusters (as shown in Figure 8) will need a 
Designated Device (DD) for assigning a unique cluster ID to individual cluster 
heads. The DD also serves to calculate the shortest route to clusters and keep 
nodes within the network informed. DD is usually the cluster head of cluster 0 
and begins by sending “hello” message. Neighboring cluster heads respond by 
sending a “connection request” message to join cluster 0 followed by a request 
for a CID to the DD. When a cluster head is assigned to a new CID, its member 
nodes are informed using the “hello” message. If a node member receives the 
“hello” message from the DD, CIDO is added to the neighboring list and updates 
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its cluster. This node will then be selected as the border node for that particular 
cluster and the “network connection” message is sent to establish a connection 
to the DD resulting in the border node being a member node of cluster 0. A “CID 
request” message is then sent and upon receiving a “CID response” message, a 
“network connection response” message containing a new CID is sent to the 
parent cluster head. Members in the cluster will be informed through “hello” 
messages. Other clusters not in the vicinity of the DD utilize intermediate clusters 
to obtain the CID. Eventually, the DD should gather the entire tree structure of 
the clusters. Individual nodes belonging to a cluster have to maintain a record of 
their parent and child clusters as well as the border node ID associated with the 
clusters. 


Cluster 2 



Figure 8 - Typical Multi-Cluster Network 


Periodic “network link state report” messages are sent by cluster heads to report 
link state information to the DD for computing route optimization and to update 
network redundancy. In return, results of the updated route are sent through a 
“topology update” message from the DD to the cluster. To prevent network 
downtime caused by the DD, a backup DD is often assigned. Border routers 
connect the clusters by performing relaying functions where messages are 
forwarded to border nodes of an adjacent cluster or a destination node that 
resides in the cluster. Only the DD can communicate with all nodes in the 
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network and the broadcast message is forwarded by the border node from the 
parent to the child cluster. 

C. OCEAN EFFECTS ON MOBILE NODES 

When nodes (devices on a buoy) are deployed in an oceanic environment, 
there are various factors that affect their movement. However, the ocean surface 
current and tidal waves have the most effect on the mobility of the nodes. 

1. Ocean Surface Current 

An ocean current can be described as a directed movement of oceanic 
water at the ocean’s surface. It can be transient, affecting a small area, or 
essentially permanent, extending over a long horizontal distance [12]. Currents 
exist at all depths in the ocean. In some regions, two or more currents may flow 
in different directions at different depths. Hence, ocean currents can be generally 
characterized into two types, surface and sub-surface. Essentially, the current 
system is complex with the actual current flow varying both spatially and 
temporally. The driving force for ocean currents comes from the atmosphere 
(mainly from winds), resulting in generation of surface circulation patterns. Such 
pattern is caused by the interaction of Coriolis deflection, wind drag and the 
pressure gradient. Wind is air moving across the Earth’s surface and is 
generated by asymmetrical heating of Earth by the sun. Although the wind 
strongly affects the surface layer, its influence on the ocean is restricted to about 
100 meters (325 feet) in depth [13 & 14]. Since this thesis is only concerned with 
surface currents which cause movement of the floating nodes, the sub-surface 
layer will not be considered. 

a. Coriolis Deflection 

Coriolis deflection is caused by the rotation of the Earth due to 
decreasing velocity at Earth’s surface with increasing latitude. The deflection 
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results in the surface current moving in a clockwise direction (bending to the 
right) in the Northern Hemisphere and counter-clockwise in the Southern 
Hemisphere (bending to the left). Therefore, the water currents will flow down the 
pressure gradient at an angle instead of directly towards the low pressure. 

b. Wind Drag 

Air at the poles is cooled and hence sinks, creating a region of high 
pressure at the surface. Differential heating on the Earth’s surface by the sun 
causes air to rise and creates a region of low pressure at the surface of the 
equator. These differences in air pressure will give rise to winds. Surface winds 
blow in a regular flow pattern and are influenced by the differential heating of air 
across Earth’s surface and Coriolis deflection. As the wind blows across the 
ocean surface, the air molecules that are dragged along the surface collide with 
the surface water molecules and transfer energy through frictional drag. This 
process results in momentum being transmitted from the air to the water 
molecules, setting the surface water in motion. 



Figure 9 - Surface Ocean Currents (from ref. [15]) 
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Due to the process being inefficient, the speed of the generated current is only 
approximately 3% of the wind speed. As such, the surface current resulting from 
wind drag is very much affected by surface winds. Eventually, currents come into 
contact with continents and are deflected, creating current loops. This 
phenomenon of creating current loops is known as circulation gyres and is shown 
in Figure 9. 

c. Pressure Gradients 

A pressure gradient is a change of pressure across a horizontal 
distance. With a greater differential pressure over a specific distance, the 
pressure gradient will increase. Ideally, pressure gradient is almost always 
balanced by Coriolis force and hence their net result causes no movement. 
However, the sea surface is warped into broad mounds and depressions. 
Mounds are caused by convergence (i.e. water flows together and sinks) while 
depressions are caused by divergence (i.e. water rises to surface and flows 
outwards). With the variation in the height on the surface, the pressure gradient 
will rise. When water is flowing down pressure gradients (high to low pressure) 
on the ocean’s irregular surface, it is deflected (a function of location and speed) 
by Coriolis. This forms a sea surface topography affecting surface circulation. 

d. Ekman Spiral 

While the surface water moves approximately 45° to the right of the 
wind in the northern hemisphere, the net transport of water is approximately 90° 
off of the wind, and a phenomenon called Ekman Transport occurs. With depth, 
the speed is reduced and the direction of the current changes. This flow pattern 
is known as the Ekman spiral, as shown in Figure 10. 


22 




Figure 10 - Ekman Spiral in Northern Hemisphere (from ref. [16]) 

Surface currents and the Ekman Transport result in the process of upwelling or 
downwelling (see Figure 11) which is an important aspect of effects along the 
coasts. When water moves to the right of wind caused by Ekman Transport, 
upwelling occurs. This movement of water offshore is replaced by cold water 
moving from below to the surface. Similarly, movement of water to the right of the 
wind direction caused by Ekman transport will results in downwelling. Water 
moved offshore is replaced by waters from below. 

V*\rtcl I rcrn 



Figure 11 - Upwelling Effect and Downwelling Effect (from ref. [17]) 


2. Tidal Current 

Tides are essentially very long-period waves that cause the sea level to 
rise and fall in response to the forces exerted by the moon and sun [13 & 18]. 


23 































Tides are phenomena caused by the gravitational pull of the sun and moon, and 
counterbalancing that force is inertia. Effectively, gravity and inertia will cause 
two major tidal bulges [19]. One of the tidal bulges is from the lunar gravitational 
attraction that “draws” the ocean to the side nearer to the moon. Another is on 
the opposite side where the inertial force exceeds the gravitational force due to 
less gravitational attraction from the moon and hence forms the other bulge. The 
size and position of the bulges are very much affected by the sun where there is 
a complex interaction between these forces and the lunar forces. 

From the horizontal movement caused by the rising and falling of tides, water 
currents are generated. There are two kinds of flow from this tidal current, flood 
flow and ebb flow. Flood flow occurs when the tidal current is coming towards the 
coast or high tide is ensuing (see Figure 12). Ebb flow is where tidal current is 
receding to the sea or low tide ensuing. The strongest currents (flood or ebb) 
usually occur before or near the time of the high and low tides. The weakest 
currents occur between flood and ebb currents, and are known as slack tides. In 
the open ocean, tidal currents are relatively weak. The speed of tidal currents 
can reach up to several kilometers per hour near coastal regions. 



Figure 12 - Ebb current at low tide and Flood current at high tide (from ref. [20]) 
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D. MOBILITY MODELS 

In order to simulate IEEE 802.15.4 protocol for an ad-hoc network, it is 
imperative to use a mobility model that accurately represents the ocean 
environment. The mobility model should attempt to represent the movement of 
actual mobile nodes floating on the sea surface. Changes in speed and heading 
must occur within reasonable time steps. 

1. Overview of Mobility Modeis 

Previous work [21] has shown that the chosen models have a great impact 
on the results of the simulation and hence the evaluation of the IEEE 802.15.4 
protocol. Essentially, such models are categorized into those that are related to 
cellular networks or ad-hoc networks. For this thesis, the main focus is on ad-hoc 
wireless networks where nodes can move freely within an area of influence. A 
route must be established between the intermediary nodes for communication 
between a pair of nodes. Hence, the modeling of the node positions is vital as 
performance is dependant on the transmission range which is fairly short with 
respect to the size of the field. Existing mobility models used in simulations can 
be divided into two distinct classes, independent or group-based. In the latter 
category, the nodes exhibit a certain relationship between each other and that 
relationship will determine the movements within the field. Independent models, 
on the contrary, model the movement of each node independently from other 
nodes. 


2. Mobility Models in BonnMotion 

Mobility models are used in NS2 to generate the scenario and such 
scenario can be generated by BonnMotion software [22]. BonnMotion software is 
a Java program developed within the Communication Systems group at the 
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Institute of Computer Science IV of the University of Bonn, Germany. It is 
capable of creating and also providing analysis of mobility scenarios. There are 
currently five mobility models, and scenarios generated can then be exported for 
NS2. The models [23,24] available in BonnMotion are the Random Waypoint 
model, two versions of Gauss-Markov model, Manhattan Grid model and 
Reference Point Group Mobility model. An overview of each model is provided 
below. 


a. Random Waypoint Mobility Model 

The Random Waypoint Mobility (RWM) model is a simplistic model 
to represent randomness in movement patterns. The required parameters are the 
pause time between changes and the direction and/or speed during each 
change. The nodes in this model will appear to move randomly within the 
confinement of the simulation boundary. Initially, nodes are placed at certain 
locations in the simulation area. During the simulation run, each node will remain 
stationary for the pause time duration. Upon the expiry of pause time, nodes will 
move toward a new arbitrary position determined by a randomly selected speed, 
uniformly distributed between a minimum and maximum speed. These nodes will 
remain in the new position until the pause time has reached and the process 
repeats until the end of simulation. Figure 13 below shows a scenario generated 
using RWM model. 



Figure 13 - RWM model scenario (from ref. [25]) 
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b. Gauss-Markov Mobility Models 

Gauss-Markov Mobility Model is designed to adapt various degree 
of randomness in the mobility pattern with the use of one tuning parameter. 
There are two models implemented, the original Gauss-Markov model and 
Gauss-Markov model. A typical scenario generated from Gauss-Markov model is 
shown in Figure 14. 



Figure 14 - Gauss-Markov mobility model scenario (from ref. [25]) 

The implementation of the original Gauss-Markov model follows the publication 
of B. Liang and Z. Flaas [24]. This model assumes that node movement has a 
pre-determined destination. Within a short period of time, the change in velocity 
will be limited due to physical constraint. Flence, the next location (and velocity) 
of a particular node is likely to be correlated to the previous and current position. 
The parameters required are a norm and random vector which are assigned to 
each mobile node, instead of stating the velocity. A maximum speed can also be 
specified. During simulation run, a velocity vector with a larger norm is multiplied 
with an appropriate scalar quantity to reduce the speed. When a node is the 
approaching boundaries and about to travel beyond the boundaries, the direction 
of movement is forced to flip by 180 degree (i.e. mirrored). This keeps the nodes 
in the boundary of the simulation area. 
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The Gauss-Markov model is similar to the description from the T. Camp, J 
Boleng and V. Davies publication [23]. There are subtle differences in the 
implementation of this model. During simulation, the new speed and movement 
direction is selected from a normal distribution of previous values, rather than 
depending on the velocity at a previous instance and a random variable. The 
speed can also be constrained within a specified range. When the speed 
exceeds this range, the minimum or the maximum value is selected. As with the 
original Gauss-Markov model, nodes can move beyond the simulation 
boundaries and the next movement vector is updated with an angle that brings 
the node back into the simulation area. 

c. Manhattan Grid Model 

The Manhattan Grid model is a model where the mobility of nodes 
is confined in a pre-defined grid area within a topological infrastructure [26]. This 
model specifies that the movement of nodes is only allowed along paths of pre¬ 
defined grid (i.e. parallel movement in the x or y direction). Figure 15 shows the 
scenario from a Manhattan Grid model. The parameters that are used to describe 
the model include the mean speed, minimum speed (with a defined standard 
deviation for speed - normal distribution), probability of speed change at position 
update and probability that node will turn at cross junctions. 



Figure 15 - Manhattan Grid model scenario (from ref. [25]) 
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Such a model is useful in emulating the movement pattern in an urban setup 
where grids are composed of a number of horizontal and vertical streets, 
intersecting each other. Node movement is somewhat driven by a destination 
and physical constraints within the environment. When a mobile node is at an 
intersection of a horizontal and a vertical street, it can turn left, right or go straight 
depending on a certain probability. 

d. Reference Point Group Mobility Model 

Reference Point Group Mobility (RPGM) model [27], unlike 
previous models, is a group mobility model and allows independent random 
motion behavior for each node, in addition to the group motion (see Figure 16). 
Nodes are formed into groups where each group will have a logical centre. The 
group movements will be based upon the path traveled by a logical center. This 
model represents the randomness in movement of groups as well as individual 
nodes within the group. Group movement is determined by the group’s logical 
centre and the motion of nodes in a group is characterized by the centre direction 
and speed. Within a group, individual nodes move depending on a pre-defined 
reference point which follows the group movement. 



Figure 16 - RPGM model scenario (from ref. [25]) 
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This model is parameterized by the number of nodes per group, group change 
probability (where nodes migrate from one group to another), maximum distance 
to center of group and group size standard deviation. The RPGM model provides 
a general and flexible framework for describing mobility patterns that are task 
oriented and time restricted. Such a model is suitable for military operation 
environment where military forces usually move in groups. 

3. Summary 

Although the RWM model is simple and widely used, it does not capture 
the essence of node movement on the ocean surface. The ocean current is 
determined mainly by the wind and not necessarily random in movement pattern. 
Both the Gauss-Markov models constrain the movement of nodes to be within a 
certain operating environment. Such properties are ideal for simulating a wireless 
personal communication service that is restricted by wireless coverage. However 
in oceanic environment, nodes could be washed ashore or drift further into the 
ocean. The Manhattan mobility model has the properties of high spatial and 
temporal dependency with a certain restriction on mobility defined by the grid. 
For modeling of ocean surface current, the movement of nodes is not 
constrained in any particular fashion except at the coast line. The RPMG is the 
most promising among the previous models as the nodes in an ocean 
environment could possibly form group since the difference in velocity of adjacent 
nodes is small. However, the velocity change is not random but deterministic and 
is influenced by surface current depending on the time of day. Hence, the models 
in BonnMotion do not accurately represent the ocean environment and cannot be 
used to provide meaningful evaluation of IEEE 802.15.4 protocol. 


30 



III. NS2 SIMULATION ENVIRONMENT 


In computer network research, the uses of network simulation techniques 
allow simulating network behavior by mathematical calculation of network 
interaction. Network simulator (NS2) is such an open source simulation tool that 
operates on the UNIX-based operating systems. This chapter describes NS2, the 
methodology used to compute node movements, generation of NS2 movement 
and traffic pattern scripts as well as the performance matrices for evaluation of 
IEEE 802.15.4. 

A. NETWORK SIMULATOR 

The network simulator, NS2, is a discrete event simulation tool for network 
simulation which will be used for evaluating the performance of IEEE 802.15.4. 
The NS2 software and documentation is currently maintained by University of 
Southern California's Information Sciences Institute (USC/ISI). NS2 began as a 
variant of REAL [28] which is a network simulator originally intended for studying 
the dynamic behavior of flow and congestion control schemes in packet-switched 
data networks. It is open-source and operates on the UNIX-based operating 
systems providing substantial support for simulation of routing, multicast 
protocols and IP protocols over wired, wireless and satellite networks. In addition, 
it has the capability to generate graphical details of network traffic (through the 
Network Animator, NAM) and supports several routing and queuing algorithms. It 
is also possible to run NS2 on Windows machine using Cygwin application, 
which provides a Linux-like environment under Windows, or simply by operating 
NS2 through a VMware player. Installation of NS2 can be done by downloading 
the all-in-one version or downloading individual components and then compiling 
each component in a single directory. Despite its capabilities, NS2 has been built 
by various developers and contains several inherent known as well as unknown 
bugs. 
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1 . 


NS2 Architecture 


NS2 is written in the C++ programming language with the Object Tool 
Common Language (OTCL) as the front-end interpreter. A class of hierarchy 
supported in C++ is the compiled hierarchy and the interpreter hierarchy for 
OTCL. There will be objects that are completely implemented in C++ or OTCL 
while some can be implemented in both languages. For objects that are 
implemented in both languages, there is a corresponding link between the two 
hierarchies. Figure 17 shows the architecture of NS2. 



Figure 17 - Architecture of NS2 

Basically, the two languages are required to complement both run-time 

speed and iteration time. A detailed simulation involving efficient manipulation of 

bytes, packet headers and implementing algorithms with large data set will 

require run-time speed. The importance of these tasks requires a system 

programming language similar to C++ programming. On the contrary, where 

certain parameters might need to be varied for research, iteration time is vital. A 

scripting language like OTCL is ideal for such a task that allows frequent 

configuration changes. A scheduler maintained event timing that determines the 

advancement of the simulation, as shown in Figure 18. An event is an object in 

the C++ hierarchy with a unique identity, a scheduled time and a pointer to an 
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object that handles events. For every event created by the network component, 
the event will be placed onto an event queue linked to the scheduler. The data 
structure is ordered to be synchronized with the executing events invoked by the 
event handler. As the simulation progresses, the first event in the queue is 
assigned with the appropriate network component and executed. 


Event Queue 

-► 



Figure 18 - NS2 Event Scheduler (from ref. [29]) 


2. Simulation Environment 

The version in use for this thesis is version 2.29, with installation of the all- 

in-one package that operates on Redhat 9.0 through VMware server. The 

installation process is available in Appendix A. Basically, the scenarios are 

implemented with scripts written in TCL that comprise commands and 

parameters for simulator initialization, node creation and configuration. There are 

three inputs to the simulator; the movement pattern file, the communication 

pattern file and the configuration file. The movement pattern file describes all 

node movements while the communication pattern file describes the packet 

workload presented at the network layer during simulation. These two files 

essentially constitute the description of the simulation scenario. The final input is 

the configuration file that defines the ad hoc network routing protocol which is 

often the main file where the scenario files are called. The results from the 

simulation are generated in two separate files, an output trace file (*.tr) and a 
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NAM trace file (*.nam). The trace file will contain information on the various 
events which occurred, details of node behavior, packet transmissions and 
receptions, communication layer, packet drops, etc. Analysis of these packets 
can determine the performance effects from parameter variation, routing 
protocols and are performed using awk command, perl scripts or available 
analysis programs. The nam file contains information on the topology such as 
node movement traces and events. It is similar to trace files with the exception of 
the syntax that is used by the network animator (NAM) for visual representation 
of the simulated scenario. The procedure for running the scenarios is shown in 
Figure 19. 



Topology animator Performance graph 


Figure 19 - Flow Diagram for Running Scenario in NS2 
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3. 


NS2 Mobile Node Model 


The mobile nodes model is part of CMU’s mobility extension [30] to NS2 
where each mobile node operates independently to compute its position and 
velocity as a function of time. Mobile nodes are attached to a channel through 
network interfaces that carry packets between nodes. Figure 20 shows the 
mobile node. As part of the mobility extension, added functionalities like node 
movement, transmission and reception on a channel are included to create a 
wireless mobile environment. 
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Figure 20 - NS2 Mobile Node Model (from ref. [30]) 
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Features including node movement, periodic position updates and maintaining 
topology boundary are implemented in the C++ portion whereas the network 
components (such as classifiers, LL and MAC) are implemented in OTCL. 
Applications such as constant bit rate (CBR) packets are bounded to a particular 
node and a routing agent. Routing agents are used by the nodes to compute the 
routes from source to destination. The packet is then passed to the link layer (LL) 
and queued until a signal is received from the MAC layer for transmission on the 
channel. During transmission, copies of the packet are distributed by the channel 
to all interfaces residing on the channel. Whether a particular interface receives 
the packet is determined by each network interface’s information and radio 
propagation model that simulate the physical nature of wireless communication. 
The simulation parameters for this thesis are described in Table 2. Identifying the 
correct parameters for the simulation is essential for realistic analysis of the 
study. There are two MAC layer protocols implemented for mobile networks, 
802.11 and TDMA. However, the simulation for this thesis is based on IEEE 
802.15.4 protocol which is part of the NS2 contributed code. 


Traffic parameters 

Traffic type 

Constant Bit Rate (CBR) application based on simple User Datagram 
Protocol (UDP). Using CBR allows the network to be tested for 
congestion that will affect delivery ratio. 

Active flow 

Active flow is the communication that is established between a node and 
the coordinator. Fifteen active flows are used for our simulation. 

Packet size 

This is the payload of a packet that excludes the MAC and PFIY layer 
headers. 

Traffic direction 

All the traffic flow from various nodes to the PAN coordinator. 

Node parameters 

No. of nodes 

There are total of 25 nodes and one of them being the PAN coordinator. 

Node movement 

Two types of scenario will be simulated, stationary nodes and node 
movements in ocean environment. 

Node position 

The nodes are placed 15m apart form each other. The PAN coordinator is 
the node at the center. 

Physical parameters 

Radio 

Propagation 

Model 

There are three models supported, Free-space, Two-ray ground and 
shadowing model. Given that nodes may not have direct line-of sight and 
communication range is limited, the radio propagation model for our 
simulation is the Two-ray ground model approximation assuming 
reflection off a flat plane. 
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Antenna 

The antenna used is omni-directional having unity transmitter and 
receiver gain. 

Path loss 

The path loss is defines as the attenuation during transmission due to 
factors like antenna height, obstruction and etc. It is assumed that there is 
no attenuation and hence the path loss is 1. 

Routing layer parameters 

Queue type 

DropTail is the queue type employed that implements the “First in First 
out” techniques. Packets entering the queue will be executed first and 
once the queue limit is reached, last packet entering the queue will be 
dropped. 

Queue length 

The queue length of 100 packets is used as the default parameter. With a 
WPAN, a large queue length is not required as the data rate is low. 


Table 2. Simulation Parameters 

4. Setting User Parameters in NS2 


For any simulation run, there is a set of control parameters to be specified 
by the user as well as output parameters that need to be analyzed. As mentioned 
earlier, the scenario which defines the environment is included in the movement 
pattern file and communication pattern file (detailed in the following section). The 
configuration file is essentially a script that consists of a general format that can 
be used to simulate any kind of routing protocol. The script begins with the 
definition of the wireless physical medium parameters and initialization of 
simulation parameters. After setting up the initial parameters, the simulator 
objects will be set up where the simulator instance, trace object for the network 
simulator and network animator as well as the General Operations Director 
(GOD) will be created. GOD is a simulator object, which is used to store global 
information about the state of the environment, network, or nodes. The topology 
is also defined where a load_flatgrid object specifies a 2-D terrain. Next, the 
properties of individual mobile nodes in the ad hoc network are defined as shown 
in table 2. Each node is then attached to the channel with movement and traffic 
specified in the movement pattern file and communication pattern file 
respectively. Finally, information to end the simulation is included. A sample of 
the script used for the simulation is attached in Appendix D. 
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5. Post Analysis 


At the end of the simulation, the two generated files can be used for 
performance analysis. The Network Animator file (*.nam) is utilized by the 
Network Animator (NAM) which is a Tcl/TK based animation tool for viewing 
network simulation traces and real world packet traces [31]. It is created to allow 
accommodation of large animation data sets and adaptable to different network 
visualization situations. Simple animation event commands are read from nam 
files to minimize memory usage. NAM supports topology layout, packet level 
animation and various data inspection tools. Upon startup, NAM will read the 
nam file and create the topology followed by displaying the layout on a window. 
Through the user interface, NAM provides several functions to control the 
animated simulation. A screenshot of NAM is shown in Figure 21. 



Figure 21 - NAM Application Window 

There are two types of trace formats that can be used in NS2. The trace files 
obtained from the simulation contains the packet dumps between nodes 
communication. The old format for wireless simulation traces begins with either 
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one of the characters s, r, D or f to denote sending, receiving, dropping and 
forwarding (i.e. node not originator) a packet respectively. The old trace format is 
as shown in Table 3. 


Event 

Abbreviation 

Type 

Vaiue 

Wireless 

Event 

Commence 
with : 
s: Send 
r: Receive 

D: Drop 
f: Forward 

%.9f %d (%6.2f %6.2f) %3s %4s %d %s %d [%x %x %x %x] 

%.9f _%d_ %3s %4s %d %s %d [%x %x %x %x] 

double 

Time 

int 

Node ID 

double 

X Coordinate (If Logging Position) 

double 

Y Coordinate (If Logging Position) 

string 

Trace Name 

string 

Reason 

int 

Event Identifier 

string 

Packet Type 

int 

Packet Size 

hexadecimal 

Time To Send Data 

hexadecimal 

Destination MAC Address 

hexadecimal 

Source MAC Address 

hexadecimal 

Type (ARP, IP) 


Table 3. NS2 Trace Format for Wireless Packet 


As a part of the effort to merge wireless traces, a new trace format [32] has been 
introduced. This revised format supports backward compatibility with previous 
trace formats and is divided into the following fields. The type field is used to 
differentiate among different types of traces. As with the old format, the new 
format has similar field types. Typically, the field type is followed by general flag 
(-t) and sets of flag/value pairs with the first alphabet of the flag type 
representing node property (N), IP level packet information (I), next hop 
information (H), MAC level packet information (M) and packet specific information 
(P) shown in Table 4. 
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Value 


Event Abbreviation Flag Type 




-t 

double 

Time (* For Global Setting) 



Next hop information 



-Hs 

int 

Hop source node ID 



-Hd 

int 

Hop destination Node ID 

-1: the packet is a broadcast packet 

-2 destination node has not been set 



Node properties 



-Ni 

int 

Node ID 



-Nx 

double 

Node X Coordinate 



-Ny 

double 

Node Y Coordinate 



-Nz 

double 

Node Z Coordinate 



-Ne 

double 

Node Energy Level 



-NI 

string 

Network trace Level (AGT, RTR, MAC, etc.) 



-Nw 

string 

Drop Reason 

Wireless 

Event 

s: Send 
r: Receive 
d: Drop 

Packet information at MAC level 

-Ma 

hexadecimal 

Duration 


f: Forward 

-Ms 

hexadecimal 

Source Ethernet Address 



-Md 

hexadecimal 

Destination Ethernet Address 



-Mt 

hexadecimal 

Ethernet Type 



IP Trace 



-Is 

int.int 

Source Address And Port 



-Id 

int.int 

Destination Address And Port 



-It 

string 

Packet Type (cbr, tcp, ...) 



-II 

int 

Packet Size 



-If 

int 

Flow ID 



-li 

int 

Unique ID 



-Iv 

int 

TTL Value 



Packet info at Application level 



-P 

string 

Packet Type (arp, dsr, imep, tora, etc.) 



-Pn 

string 

Packet Type (cbr, tcp, ...) 


Table 4. NS2 New Trace Format for Wireless Packet 


Depending on the packet type, the trace may log additional information. For the 
simulation performed, there are three packet types, ARP, GBR and AODV. The 
format for the ARP, GBR and AODV trace are shown respectively in the tables 
below. 
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Event 

Flag 

Type 

Value 

ARP 

Trace 

-Po 

string 

Request or Repiy 

-Pms 

int 

Source MAC Address 

-Ps 

int 

Source Address 

-Pmd 

int 

Destination MAC Address 

-Pd 

int 

Destination Address 


Table 5. ARP Trace Format 


Event 

Flag Type 

Value 


|-Pt hexadecimai 

Type 


|-Ph int 

Hop Count 


|-Pb int 

Broadcast ID 

AODV 

|-Pd int 

Destination 

Trace 

|-Pds int 

Destination Sequence Number 


|-Ps int 

Source 


|-Pss int 

Source Sequence Number 


|-Pi doubie 

Lifetime 


|-Pc string 

Operation (REOUEST, REPLY, ERROR, HELLO) 


Table 6. AODV Trace Format 


Event 

Flag 

Type 

Value 

CBR 

Trace 

-Pi 

int 

Sequence Number 

-Pf 

int 

Number Of Times Packet Forwarded 

-Po 

int 

Optimai Number Of Forwards 


Table 7. CBR Trace Format 

For analyzing the performance of IEEE 802.15.4, information has to be extracted 
to compute the performance parameters from trace files using AWK or Perl 
script. AWK is a programming language designed for processing text-based data, 
either in files or data streams. Perl is a dynamic programming language that 
complements AWK to allow processing of repetitive simulation runs. Both 
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languages are available in standard UNIX environment. Java program can also 
be implemented to analyze the trace files. 

B. GENERATING OCEAN ENVIRONMENT SCENARIOS 

As the above mobility models do not correctly represent the oceanic 
environment, there is a need for other means to generate the movement pattern 
file. Another alternative is to compute node movements using actual surface 
current measurements. In NS2, movement files are generated from mobility 
models or by using node movement generator. The node-movement generator 
allows configuring of nodes movement at particular time and is available under 
~ns/indep-utils/cmu-scen-gen/setdest directory consisting of setdest{.cc,.h} and 
Makefile. The setdest function can then be used to create the movement 
scenario for NS2. The other part of the scenario is to define and generate the 
communication pattern file. 

1. Near Real-Time Monterey Bay Surface Currents 

Near real-time coastal surface current data of the Monterey Bay 
(California) are made available from a collaboration between the Naval 
Postgraduate School, University of Delaware and Monterey Bay Aquarium 
Research Institute [33]. Four High Frequency (HF) radars at different locations 
measure the currents and the measurements are objectively mapped to fill gaps 
in space and time. Mapping is required due to environment factors causing 
unavailability and spatial coverage of the HF radar measurements. The results of 
hourly mapped total vectors will be used for the computation of node movements. 
The ASCII data files contains the hourly data of pre-determined locations in 
latitude/longitude (lat/long) with the vector speed (cm/s) shown in Figure 22. 
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Loncrit.ude 

Latitude 

U (cm/ 3 ) 

1 V ^ cm/: 

-122.IS69 

36.5S99 

23.8243 

-7.5657 

-122 .1307 

36.5399 

30.0602 

-15.5001 

-122.17^^ 

36.5099 

29.2442 

-15.9209 

-122.1S82 

36.5899 

28.6S70 

-16.3433 

-122.1S20 

36.5099 

20.2209 

-16.7316 

-122.1557 

36.5899 

27.8382 

-17.0822 

-122.1495 

36.5899 

27.4390 

-17.3813 

-122.1432 

36.5899 

26.9970 

-17.6144 

-122.1370 

36.5899 

26.4484 

-17.7648 

-122.1305 

36.5599 

25.7655 

-17.G137 

-122 - 1245 

36.5399 

24 - 9£i05 

-17.7392 


Figure 22 - Data points of Monterey Bay 


2. Determining Mobiiity Using Actuai Measurements 


A sample data set (dated 30 January 2005) of the Monterey bay area was 
taken to simulate the nodes’ movement. Since the variation is small across each 
time step, the hourly velocities are linearly interpolated for the entire day at a time 
interval of 10 minutes. Computation was performed for an entire day at a time 
interval of ten minutes. Basically, the velocity vectors of the data points nearest 
to the node were referenced to provide a random velocity from a normal 
(Gaussian) distribution. The randomness was included to account for turbulent 
diffusion and was applied to the node. This turbulent motion included the 
meandering of the current, tides, waves, and random motion which caused the 
nodes to disperse. The next position of the node was computed and the 
computation was repeated until the end of the day. The following sub-paragraphs 
detail the steps (performed using Microsoft Excel) to compute a node movement 
when placed within the Monterey Bay area. 

Step 1: The initial position (lat/long) of the node is searched through 

the data files for nearest data points beginning at OOOOhrs. 
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step 2: The velocity of the data points nearest to the node were 

referenced and a random velocity was generated from a 
normal (Gaussian) distribution which was applied to the 
node. This velocity then computed the distance and 
direction of the next position for a period of 10 minutes. 

Step 3: The coordinates of the next position were computed using 

the formula [34] given below. The computation repeated 
until the boundaries of the bay were exceeded or simulation 
time (one day) was reached. 

Latitude (x) = arcsin(sin x'cosd + cos.^'sin d cos t^) (1) 

Longitude (y) = mod(y' - arcsin(sin t^ sin d / cos x) + TT, 2m:) - M (2) 

where 

x' is the latitude of the current location, 
y' is the longitude of the current location, 
d is the dis tance in radians, 
t^ is the true course heading in radians. 


The result of simulating 25 nodes placed 10m apart from adjacent nodes within 
the Monterey Bay is shown in Figure 23. Initially, nodes can be seen to be 
moving towards the shore and around llOOhrs, nodes start to drift out towards 
the ocean. Nodes are gradually dispersing away from each other until the end of 
the day. Such a dispersing behavior is consistent with the meandering of the 
current, tides, waves, and random motion. Also, since the nodes are within the 
bay area, the movements are very much dominated by tidal currents. This 
pattern is unique which cannot be correctly modeled by any models. Hence, the 
data (node position at various times and speed) obtained from the computation 
will be used for the simulation. 
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Figure 23 - Node movements in Monterey Bay 


3. Generating Movement Pattern File 


A movement pattern file is required as an input to NS2 for the simulation. 
An external script (see Appendix B) is implemented to parse the computed 
movement data and generate the mobility file. The script is written in Tool 
Command Language (TCL) and essentially functions to format the data into the 
movement file. The movement file consists of initial position of each node (two 
dimensional) and the “setdest” commands for each movement change at 
stipulated time. Subsequently, the formatted file can be used to calculate 
information for GOD (General Operations Director) object which can also be 
present in the movement. The “calcdest" function (found in ~ns/indep-utils/cmu- 
scen-gen/setdest/ directory) is used in which information of the GOD object is 
computed and loaded into the movement file. The GOD object is initially used to 
store global information about the state of the environment, network, or nodes 
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but currently stores an array of the shortest number of hops required to reach 
from one node to another. The calculation is performed in advance to minimize 
computation time required during simulation. 



Figure 24 - Process of Generating Mobility File 


Figure 24 depicts the process and results generated from the script. It was 
discovered that the nodes had to be arranged in an anti-chronological order for 
the correct execution of “calcdest” function. The script below is modified from a 
sample script provided by Matthias Budde in the NS forum, customized to our 
computed data. This script essentially parses the numerous data generated by 
the node movement computation using the “Tcish” command. “Tcish” is a shell 
like application that reads and evaluates TCL commands from standard input or 
a file. Data points are extracted and arranged in the required format of the 
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movement file. The computed movement data have to be arranged in anti- 
chronological order for subsequent computation of GOD object. 

4. Generating Communication Pattern Fiie 

The communication pattern file essentially describes the packet workload 
presented at the network layer during simulation. A TCL script is modified from a 
constant bit rate generation script file [35] specifically design for star topology. 
The modification includes change to generate traffic at an interval of 10 minutes 
which coincide with node movements where nodes will be randomly selected to 
transmit data to the PAN coordinator (see Appendix C). The script can be 
executed using “ns” command, followed by optional parameters. These 
parameters specify the traffic type (cbr or top), number of nodes in the scenario, 
seed for generating random traffic pattern, maximum traffic flow, traffic rate, start 
time, end time and the time gap between consecutive transmissions. The traffic 
scenario is then piped to a communication pattern file. 

C. PERFORMANCE METRICS 


In this thesis, the performance of IEEE 802.15.4, in particular, the Quality 
of Service (QoS) is to be evaluated against the oceanic environment. The QoS is 
determined by a set of service requirements that the network must fulfill when 
transporting packet streams from a source to its intended destination. Due to the 
mobility and dynamic nature of the MANET, resources might not always be 
available and parameters such as throughput, delay and packet drop have to be 
considered. Essentially, two scenarios are used for the simulations, stationary 
nodes and mobile nodes floating on the ocean. Three performance metrics will 
be used to determine the QoS provided by IEEE 802.15.4. A detailed explanation 
of these metrics is as follows: 
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1 . 


Packet Delivery Ratio 


Packet Delivery Ratio (PDR) is the quotient resulting from the number of 
successful delivered GBR packets to those generated by GBR sources within the 
simulation period. It is an important metric which indicates congestion level of the 
network. PDR measures the protocol performance from loss ratio experienced at 
the network layer that is affected by factors such as packet size, network load 
and effects of movement resulting in frequent topological changes. Higher PDR 
implies that packet loss rate is lower and protocol is more efficient from the 
perspective of data delivery. A point to note is that late packet received could be 
deemed useless even with high PDR. 


PacketDeliveryRatio (PDR) = 


^ Number of received CBR packets 
^ Number of transmitted CBR packets 


( 3 ) 


2. Average Network Delay 

Network delay is the time delay experienced by a connection between 
nodes. This delay includes all possible delays that are caused by route discovery 
latency, queuing in the interface queue, retransmission at the MAG layer and 
propagation through the environment. This delay can be computed as the 
difference in time from transmitting packets from a source to the arrival of 
packets at the destination node. All the connection delays are aggregated and 
the average network delay is the aggregated delay divided by the number of 
connection pairs throughout the simulation. 

. AT . I TA 7 packet arrive @ dest packet sent @ someth /as 

Average Network Delay - — - (4) 

Total number of connection pairs 
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3. Network Throughput 


The network throughput determines the amount of data that is transmitted 
from a source to a destination node per unit time (bits per second). While 
ignoring the overheads in the network, only the data of the GBR packets are 
considered. Node throughput is a measure of the total number of data packets 
successfully received at the node, having the total number of bits is computed 
over the simulation runtime. The network throughput is then derived from the 
average throughput of all nodes involved in the GBR packet transmission. 

, Total bits received by node 

Node Inrougnput - - (o) 

Simulation time 

V Node Throughputs of CBR transmission , , 

Network Throughput = - — - - - (6) 

Total number of nodes 
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IV. SYSTEM SIMULATION AND RESULTS 


This chapter identifies additional parameters to be used in the simulation 
with reference to a Zigbee transceiver as well as the analysis of IEEE 802.15.4 
against the performance metrics. The performance metrics are used in deriving 
the performance specific to mobility, node density and network loading. The 
simulation is reiterated over several runs until certain conclusions can be drawn 
to determine the feasibility of employing IEEE 802.15.4 technology in the ocean 
environment. 

A. SPECIFIC TRANCEIVER PARAMETERS 


Besides physical parameters defined in the previous chapter, the 
specification of the transceiver plays an important role in determining the 
communication range of the nodes. The power parameter is based on the 
specification of Crossbow MICAz processor and radio platform (MPR2400CA). 

1. Transmitted Power (Pt_) 

The transmitted power is the power that is transmitted from the antenna 
into space. In Annex F [4], the document states the IEEE 802.15.4 regulatory 
requirements that for the ISM band 2.4 GHz operating in United States, 
transmitted power of up to 1 watt is provided. Although IEEE 802.15.4 devices 
are generally envisioned to operate with a maximum transmit power of 
approximately 0 dBm (ImW), a minimum of +10 dBm (0.01 W) is allowed in this 
band. The crossbow RF transceiver has power of -24 dBm to 0 dBm, hence 
1 mW for Pt_ will be used in the simulation. 

Pt_ = QdBm = lmW (7) 
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2. 


Receiver Threshold (RXThresh_) 


The receiver threshold is the parameter used to specify the 
communication range of the wireless nodes and the threshold is the minimal 
power of the packet required for successful reception. If a packet reaches a node 
with a power level above the receiver threshold, the receiver will be within the 
transmission range of the sender. The receiver sensitivity for the crossbow 
transceiver is -94 dBm typical. Taking the typical receiver sensitivity, the receiver 
threshold is -94 dBm which is equivalent to 3.981 x 10'^^ W. 

RxThresh _=-9AdBm = 3.98lx 10“*^ IK (8) 

3. Carrier Sensing Threshold (CSThresh_) 

The carrier sensing threshold describes the sensing range of a node. 
When the received packets have a power level below the receiver threshold but 
above the carrier sensing threshold, the receiver is within the carrier sensing 
range but decoding of the packet is not guaranteed. The sensing range of a node 
is usually greater than the transmission range. Hence, it is assumed that the 
carrier sensing threshold value is at least the receiver threshold. 

CSThresh _ = RxThresh _ = 3.981x10"'^ IK (9) 


4. Capture Threshold (CPThresh_) 

During packet transmission, it is possible that two packets can 
simultaneously arrive (i.e. collision) at the receiving node. In NS2, only packets 
received in the carrier sensing range of a receiver are considered as potential 
sources of packet collisions. The capture threshold determines if a packet is 
successfully received by comparing the power ratio of both packets. The packet 
with the highest ratio that is greater than the capture threshold is chosen. The 
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capture threshold (CPThreshold) is assumed to be 10 dB in the simulations 
which is a common value used in most simulations. 


CPThresh _ = 10 dB 


( 10 ) 


5. Antenna Height 

For the simulation environment, the antenna of a particular node will be 
mounted on a floating buoy. Assuming that the buoy has a diameter of 1 m and is 
partially submerged, the antenna will be at a height of approximately 0.5m. In 
NS2, the antenna is defined as a set of three dimensional coordinates with the z 
dimensional coordinate being antenna height. 

X _=0m 

Y_ = 0m (11) 

Z_ = 0.5m 


6. Propagation 

There are 4 types of models used in NS2 to represent the radio 

propagation properties of the environment, namely the free space, two-ray 

ground, Ricean, Rayleigh and shadowing models. The free space model is a 

large scale model where the received power is dependent on transmitted power, 

antenna gains and the range between communicating nodes. The model 

essentially accounts for the decrease in power as the range increases. As with 

free space model, the two-ray ground model is also a large scale model. The 

difference being that the two-ray ground model considers the received power 

from both the direct path and a ground reflection path. However, a limitation 

posed in NS2 is that both the communicating nodes have to be of the same 

height. Both the Ricean and Rayleigh are fading models that describe the 

propagation effect of a RF signal in a defined environment. Rayleigh fading is 

most applicable when there is no line of sight between communicating nodes 
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while Ricean fading is more applicable if there is a line of sight. Finally, the 
shadowing model assumes the average received signal power decreases 
logarithmically with distance. A Gaussian random variable is added to the path 
loss to account for environmental influences at the sender and the receiver. 
Considering the complex ocean environment, the propagation may vary in 
different location. For simplicity, the two-ray ground model is selected. According 
to the two-ray ground propagation model, the sensing range of the device is 
computed to be 112m. 

B PERFORMANCE ANALYSIS 

In practice, node movements in the ocean will result in the network having 
to re-learn optimum routes. Several experiments are conducted to analyze the 
behavioral response of the IEEE 802.15.4 network, utilizing a Zigbee transceiver 
that is operating at the 2.4 GFIz frequency band. Essentially, the influence of 
mobility, node density and network loading on the network will be studied. In 
particular, the network’s packet delivery ratio, delay and data throughput 
performance are measured with varying transmission rates. The performances 
resulting from the metrics are presented with moving scenarios. To increase the 
confidence level of the results, a set of simulation parameters are performed with 
various random seeds for the data transmission. Flowever, running the scenarios 
required long simulation hours for node movements within a day. 

1. Simulation Setup and Parameters 

Wireless networks based on IEEE 802.15.4 are designed for low data rate 
and low power consumption devices. Depending on the operating requirements 
and environment, there has to be compromises between the node transmission 
range, operational lifespan and device cost. The transmission range can be 
determined from Friss two-ray ground reflection models which relates the 
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maximum range to the antenna gain, transmit power and receiver sensitivity. 
With the Crossbow MICAz processor and radio platform, the maximum range is 
computed to be approximately 112m. Since the nodes are highly mobile, this 
range will determine if a data packet can successfully arrive at the destination 
node. The data traffic type is Constant Bit Rate (CBR) with the application agent 
sending at a rate of 20 data packets per second continuously. The nodes used in 
the simulation will be placed at predetermined distances from adjacent nodes 
covering an area of 40m by 40m. The centre node is designated the PAN 
coordinator with all other nodes randomly transmitting data packets to the PAN 
coordinator. The speed and heading of each node will vary according to the 
generated ocean movement with a maximum simulation runs of 12 hours. The 
simulations are conducted with the typical parameters shown in Table 8. 


Simulation Parameters 

Protocol 

AODV 

Simulation Time 

Ihr, 3hrs, 6hrs, 9hrs, 12hrs 

# of Nodes 

9, 16, 25 

Map Size 

4500m X 4500m 

Speed 

Varying from 0.006m/s-0.47m/s 

Mobility Model 

Actual Measurement Model 

Traffic Type 

Constant Bit Rate (CBR) 

Packet Size 

20 bytes 

Connection Rate 

0.05 to 5 packets per second 


Table 8. Simulation Parameters 


During the simulation, certain behaviors are exhibited by the nodes if 
communication cannot be established with the coordinator. When a node losses 
synchronization, orphan-scanning is performed to relocate the coordinator. When 
coordinator relocation is successful, communication will resume. If relocation of 
the coordinator fails, node will subsequently perform active channel scan to send 
association request to the PAN coordinator. Upon successful association, the 
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node begins to transmit beacons and start data transmission. Else, non-beacon 
mode is enabled for that node. 


2. Influence of Node Density 


In an ocean environment, the number of nodes providing coverage in an 
area of operation will determine the performance of sensors (i.e. detection range) 
used in the nodes and ultimately derive the cost of operation. As such, the 
performance of the network is measured with varying node densities to ascertain 
the impact. In this set of simulations, the node density is increased from 9, 16 
and 25 nodes within operational coverage of 40m x 40m. Figure 25 shows the 
initial node placement within the operating area. 



25 nodes covering 40m x 40m 

X X3 A4 

7 X 8 9 

12 

X'^ 13 14 

PAN coordinator 

Ol7 -18 #19 

22 

■ 23 ♦ 24 

Figure 25 - Initial Coverage with 9, 16 and 25 Nodes 
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Three sets of scenarios, namely the 1,3 and 6 hours runtimes, will be used as a 
basis of comparison with GBR traffic at a data rate of 0.1 packets per second. 
For each scenario set, the number of connections is set to 8, 14 and 20 
respectively where all nodes are transmitting packets to the PAN coordinator. 
The designated PAN coordinator and nodes positions after the respective 
simulation runtime are shown in Annex G. The rest of the simulation parameters 
remain relatively unchanged. Table 9 summarizes the simulation parameters for 
this set of simulations. 


Simulation Parameters 

Protocol 

AODV 

Simulation Time 

1 hr, 3hrs, 6hrs 

# of Nodes 

9, 16, 25 

Max Node Connect 

8, 14, 20 

Map Size 

4500m X 4500m 

Speed 

Varying from 0.006m/s-0.47m/s 

Mobility Model 

Actual Measurement Model 

Traffic Type 

Constant Bit Rate (CBR) 

Packet Size 

20 bytes 

Connection Rate 

0.1 packets per second 


Table 9. Simulation Parameters for Node Density Analysis 


In general, due to the highly dynamic nature of node movement, low density may 
cause the network to be frequently disconnected resulting in a low throughput. 
The experimentation goal is to determine the network scalability rather than to 
find the optimal node density. Figure 26 shows the simulation results which 
demonstrate the performance metrics using different node densities. An 
interesting observation is that after an hour of simulation, the packet delivery ratio 
(PDR) remains close to 100% despite the difference in node densities. This is 
due to the node transmission range and also the dispersion of nodes since the 
movements remains insignificant. As the simulation time approaches three hours, 
there is a slight reduction in PDR but still well within the 90^*^ percentile range. 
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Thereafter, the PDR falls below 90%. 


Packet Delivery Ratio vs Node Density 
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Figure 26 - Results of Varying Node Density with (a) PDR (b) Average network 

delay and (c) Network Throughput 
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An interesting observation is that the density of 16 nodes performs better as 
compared to the others, which is unexpected. This could be due to the maximum 
number of connections in each scenario. Since all the packets are effectively 
sent to the PAN coordinator, the 25-node configuration means that more packets 
are sent to the PAN coordinator resulting in collisions. As for the 9-node 
configuration, the PDR reduces as the simulation time increases due to the 
spreading of node movement. The delay measured is the average transmission 
time of all data packets. The 25-node configuration experiences the most delay 
since some of the packets are required to be forwarded by adjacent nodes before 
reaching the PAN coordinator. Also, as the nodes are much dispersed at the 
three hours simulation time, the effect is multiplied resulting in an increased in 
average network delay. The throughput effectively determines the amount of 
data that is transmitted and successfully received during the simulation time. In 
general, the network throughput increases cumulatively as the time increase. At 
the 6 hours, the network throughput of the 16-node configuration can be seen to 
perform better than the 25-node configuration. This observation reinforced the 
earlier PDR observation since more data is received at the destination. 
Effectively, the node density directly influences the achievable network 
throughput. The above findings have indicated the node density does influence 
the performance of 802.15.4. An ideal node configuration has to be determined 
considering the operational area as well as the nodes dispersion in the ocean. 

3. Influence of Network Loading 

In this simulation, the influence of network loading is studied. The emphasis is on 
the behavior of the network since IEEE 802.15.4 is primarily designed for low 
bandwidth applications. However, depending on the operational needs, a higher 
loading might be required in certain situations. The data rate is gradually 
increased from 0.005 packets per second to 50 packets per second in the three 
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node configuration scenarios. As in previous simulation, the parameters used 
remains are relatively unchanged. Table 10 summarizes the simulation 
parameters for this set of simulations. 


Simulation Parameters 

Protocol 

AODV 

Simulation Time 

Ihr 

# of Nodes 

9, 16, 25 

Max Node Connect 

8, 14, 20 

Map Size 

4500m X 4500m 

Speed 

Varying from 0.006m/s-0.47m/s 

Mobility Model 

Actual Measurement Model 

Traffic Type 

Constant Bit Rate (CBR) 

Packet Size 

20 bytes 

Connection Rate 

0.005 - 50 packets per second 


Table 10. Simulation Parameters for Network Loading Analysis 


Since all nodes have the PAN coordinator as the destination, the increase in 
network loading will increase the probability of collision at the PAN coordinator. 
Figure 27, 28 and 29 depict the effects of network loading on the performance 
metrics by increasing the connection rate from 0.05 to 50 packets per second. 
The packet delivery ratio generally has a declining trend for the three node 
configurations when the connection rate is increased. It can be observed that the 
packet delivery ratio remain in the QO'*^ percentile range till a specific data rate 
(approximately 0.3 packets per second, 0.75 packets per second and 1.5 packets 
per second for the 25, 16 and 9 nodes scenario). Thereafter, the packet delivery 
ratio performance decreases exponentially for higher data rates indicating that 
the network is congested. As the data rate increases, more packets will be 
dropped due to collision and bad link quality of transmitted packets. The resulting 
effect is the exponential increase in re-transmission of packets and hence further 
congesting the network. An ideal operating data rate can determine the efficiency 

of data delivery. For the above reason, regardless of the operational needs, the 
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application has to maintain a low data rate. In the worst case scenario, the IEEE 
802.15.4 protocol cannot be used for data rates above 0.3 packets per second in 
which performance will be unacceptable. 


Packet Delivery Ratio vs Data Rate 



0 10 20 30 40 50 60 

Data Rate (pkts/s) 


Figure 27 - Results of Packet Delivery Ratio with Varying Data Rate 

Theoretically for network delay, the increase in data rate will increase the time for 
the data packet to reach the intended destination. However, the average network 
delay from Figure 28 can be seen to be generally low, fluctuating between 0 to 
0.6 second. The peaks at low data rate experienced by both the 16-node and 25- 
node configuration could be due to the time required for packets to be forwarded 
from outer modes to the destination. The 9 nodes configuration is not affected 
since packets are sent directly to the PAN coordinator. At higher data rates, 
collision will occur. However, computation of average network delay does not 
consider dropped packets hence the delay reduces. Overall, the 25-node 
configuration experiences a higher delay as compared to the other 
configurations. 
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Ave Network Delay vs Data Rate 



Figure 28 - Results of Average Network Delay with Varying Data Rate 
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Figure 29 - Results of Network Throughput with Varying Data Rate 


Figure 29 highlights the throughput analysis of the network. The impact on the 

throughput is apparent with different node configurations. It is observed that the 

network throughput increases linearly as the data rate is increased till a certain 

throughput for each configuration. Subsequently, the throughput remains almost 
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stagnant (gradual increase), possibly due to network congestion. The peak 
performance can be considered to be in the region of 5 to 8 packets per second. 
The 9-node configuration will have the highest throughput since all configurations 
has similar data rate but require less time for data to reach the destination. 

4. Influence of Mobility 

For the analysis of mobility effects on the network, the performance 
metrics are measured at various time intervals of the simulation and for the three 
node configurations. Since object movements, especially vessels or divers, in an 
ocean environment are relatively slow and do not change direction rapidly, a low 
data rate is considered. The movement of individual nodes will follow the path as 
computed from actual ocean data with the application agent transmitting at 0.01 
packets per seconds, which is below the 0.3 packets per second data rate where 
the performance is deem acceptable. 



Figure 30 - Node Movements after 1 hour 

To accommodate the node movements, a map size of 4500m x 4500m is 

considered for the simulations. The AODV routing protocol is applied to all 
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scenarios with the simulation runs varied at intervals in the region of 1 to 24 
hours. An illustration of node mobility in the Network Animator (NAM) is shown in 
Figure 30 where the 25 nodes are dispersed after an hour of simulation. The 
node positions at various intervals of the three node configurations are as 
appended in Annex G. 


The packet delivery ratio for this simulation is shown in Figure 31. The result 
shows that both the 25-node and 16-node configurations can achieve a PDR of 
approximately 80% and higher throughout the entire simulation. The 25-node 
configuration does not perform as well possibly due to more collisions that occur. 
Comparatively, the 9 nodes configuration has the worst results where the PDR 
reduces from above 80% till about 20% at the end of the 24 hours simulation. 
Intuitively, the PDR is expected to drop in the 9 nodes configuration since each 
node is required to provide a much larger coverage as the ocean current caused 
the nodes to be spread further apart. 


Packet Delivery Ratio vs Movement in Time 
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Figure 31 - Results of Packet Delivery Ratio with Node Movement in Time 
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Figure 32 shows the results for the network delay and throughput. In general, the 
network latency for the three configurations is below 0.1 seconds after the three 
hour simulation. The latency for the 9-node configuration is much lower since all 
nodes transmit directly to the PAN coordinator. An interesting observation is that 
in the first hour, the delay of network is comparatively higher in the 16-node 
configuration than the 25-node configuration. This behavior is attributed to the 
PAN coordinator being placed in an asymmetric position in the 16-node 
configuration as well as the distance between adjacent nodes. 



Figure 32 - Results of Network Delay & Throughput with Node Movement in Time 
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The network throughput in general, increases steadily over the entire simulation 
time. There is however a reduction in the throughput for the 9-node configuration 
scenario at the ninth hour. Since the trace files are too large to be analyzed, a 
probable reasoning can be deduced from the node positions. From Figure 33, the 
node positions of the 9-node configuration indicate that the PAN coordinator has 
drifted away from the other nodes in the ninth hour. Considering the sensing 
range, all the packets have to be routed through Node 1 to the PAN coordinator 
which results in the throughput reduction. 



Figure 33 - Positions of 9 Nodes Configuration at the 9*^^ Flour. 

5. Drop Packet Analysis 

As discussed in the above findings, packet drops will affect the system 

performance. Flence, an analysis is performed to study the likely cause for 

packets to drop. From certain trace files which are smaller in file size, it was 

observed there are two drop reasons that are of interest. In the network, packet 

drops are due to IFQ and LQI that occur frequently during data transmissions. 

IFQ is prompted when transmission rate exceeds the capacity of the queue. 

When that happens, the packets that join the queue first are serviced while the 

last is dropped (FIFO). A packet drop caused by LQI indicates that the link quality 

of packets arrived at the MAC layer is not within the acceptable threshold of the 
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CPThresh value. Such a drop is mainly caused when nodes have drifted apart. 
Hence, to reduce packet drops in the network, the queue length or the 
transmission range can be increased. Both queue length and transmission range 
is a hardware limitation determine by the buffer size and the transceiver on the 
device. 

C. SUMMARY 


In this chapter, simulations are conducted to analyze the performance of 
IEEE 802.15.4 in an ocean environment. The results based on the performance 
metrics of node density, network loading and mobility influences are discussed. 
In general, the network performance is very much affected by the node 
movements in the ocean. However, with the right selection of parameters, 
operating IEEE 802.15.4 is possible in ocean environment. However, these 
results cannot be applied in general as the mobility model only reflects the ocean 
condition at the Monterey Bay. In reality, the mobility of nodes will differ 
depending on the location. The next chapter concludes the analysis and the 
findings as well as recommendations for future possible research areas. 
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V CONCLUSIONS, RECOMMENDATIONS AND FUTURE 

WORK 


A. CONCLUSIONS 


This thesis is focused on determining the performance of IEEE 802.15.4 
protocol in an ocean environment, in particular the surface current causing 
movement of floating nodes. A detailed study on the IEEE 802.15.4 architecture 
and the layered structure as well as the simulator environment has been 
conducted. All the simulations are conducted using open-source software, 
Network Simulator (NS2). Although mobility models are available in NS2, there 
are no suitable models to represent node movements in the ocean environment. 
Hence, actual measured ocean data of the Monterey Bay area is used as a basis 
for computing the movements. As the behavior of surface current differs from 
locations, the results from the analysis can only be representative of the 
Monterey Bay area. 


For the purpose of conducting a near realistic simulation, the Zigbee transceiver 
parameters used are based on the specification of Crossbow MICAz processor 
and radio platform (MPR2400CA) which operates at 2.4 GHz. All the parameters 
are then incorporated into the TCL scripts. A detailed performance study is 
performed to determine the performance of IEEE 802.15.4, in particular to the 
performance metrics. The simulation results have indicated that the network 
performance is very much affected by the node movement in the ocean. Also, 
such technology can be successfully deployed for low data rate applications. 
However, by selecting an appropriate node configuration and network 
parameters such as data rate and transmission power, the network performance 
can be further optimized. 
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B. FUTURE RESEARCH AREAS 


The results from the simulation have provided some insights into the use 
of IEEE 802.15.4/Zigbee wireless technology in an oceanic environment. Due to 
the time constraint and learning curve for NS2, certain simulation parameters are 
assumed and several features have not been studied. Hence, there are still other 
open research problems that are not addressed and also the simulation 
parameters in NS2 can still be further improved to represent the actual 
environment and deployed devices for more realistic result. The following details 
some key areas (non-exhaustive) for future research that can be used in future 
thesis research work to either augment the results made in this thesis or 
conducted in an independent thesis work. 

1. Vertical Node Movement in Oceanic Environment 

The current ocean model used in the simulation assumes a flat topology 
and only considers the horizontal movement of the nodes. In the actual ocean 
environment, the waves could cause lateral movements that result in intermittent 
connection due to the line-of-sight between nodes. A 3D mobility model can be 
created using the setdest function by defining the z parameter for the nodes. 

2. Propagation Model 

There is a need to refine the two-ray ground model used in the simulations 
to represent the ocean environment. The ocean is a harsh environment for 
propagating radio waves due to wave blockage, scattering and reflection of 
signals by the ocean surface causing multipath propagation which results in 
signal fading or signal loss. The Advanced Refractive Effects Prediction System 
(AREPS) model [36] is currently in use by the Navy and can be used to accurate 
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model the RF propagation on the ocean surface. The APEPS model takes into 
account factors that affect radio wave propagation in the maritime environment, 
including atmospheric refraction and surface reflections. 

3. Node Energy Consumption 

One of IEEE 802.15.4’s features is the low-power consumption property. 
Hence, power consumption of the node is vital which provides another dimension 
to measure the performance. This can be accomplished by including an energy 
model into the simulation and also implementing or modifying existing codes to 
include low power mode. The energy consumption can then be investigated at 
the mobile nodes. 

4. Security Considerations for Network 

There are certain security risks in utilizing IEEE 802.15.4 such as 
eavesdropping, packet injection, replay, jamming and application vulnerabilities. 
Some of these risks can be eliminated with three security options in IEEE 
802.15.4. The confidentiality aspect is addressed through the use a stream 
cipher encryption while integrity is addressed using a message integrity code 
(MIC) to protect data from being modified without the appropriate cryptographic 
key. The replay protection is implemented with the use of sequence number. 
Although the inclusion of these security mechanisms is necessary, the impact of 
the network performance has to be assessed. 

5. Guaranteed Time Slot Management 

GTS implementation is particularly effective for application that has timing 
constraints where each device is allocated specific time duration for high priority 
communication. The performance of IEEE 802.15.4 guaranteed time slot (GTS) 
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management scheme is not investigated in this thesis. Performance such as 
bandwidth utilization and data transfer reliability can be investigated. 
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APPENDIX A - INSTALLATION OF NS2 


The NS2 is designed to operate on UNIX based operating system but it is 
also possible to run NS2 on Windows machine using Cygwin or on a VMware 
server. The following detailed the step for installation. 

1. Download the all-in-one package (ns-allinone-2.29.tar.gz) from 
http://www.isi.edU/nsnam/ns/ns-build.html#allinone. The package contains 
the necessary components as well as an install script. 

2. A new directory is created {“mk ns’) and the compressed file is extracted 
into the new directory {“tar -xzf ns-allinone-2.29.tar.gz’). After extraction, 
change directory into ns-allinone-2.29 and run “Jinstair. The install script 
will automatically configure, compile and install the components. If the 
installation is successful, the below message will be received. 


Please put /root/ns/ns-allinone-2.2 9/bin:/root/ns/ns-allinone- 

2.29/tcl8.4.13/Unix:/root/ns/ns-allinone-2.29/tk:8.4.13/unix into your 
PATH environment; so that you'll be able to run 
itm/tclsh/wish/xgraph. 

(1) You MUST put /root/ns/ns-allinone-2.30/otcl-l.12, /root/ns/ns- 

allinone-2 . 30 /lib, into your LD_LIBRARY_PATH environment 

variable. 

If it complains about X libraries, add path to your X libraries 
into LD_LIBRARY_PATH. 

If you are using csh, you can set it like: 

setenv LD_LIBRARY_PATH <paths> 

If you are using sh, you can set it like: 

export LD_LIBRARY_PATH=<paths> 

(2) You MUST put /root/ns/ns-allinone-2.29/tcl8.4.13/library into 
your TCL_LIBRARY environmental variable. Otherwise ns/nam will 
complain during startup. 


3. Navigate back to the root directory and there will be a .bashrc file. This is 
the file to place the necessary path environment and a backup of this file 
is created to allow restoration to original state if anything fails {“cp .bashrc 
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.bashrc.origin’). Environment variables are variables that Unix keeps track 
of at the shell level. 

4. The .bashru file can be edited using gedit program and including the 
following script (directory can be different depending on where ns2 is 
installed) at the end of the file. With the current console window still open, 
go to another console window and determining the contents of 
environment variables by issuing the echo command. 

PATH=/ root/ns/ns-allinone-2.29/bin:/root/ns/ns-allinone- 
2.29/tcl8.4.13 /unix:/root/ns/ns-allinone-2.29/tk;8.4.13/unix: $PATH 

LD_LIBRARY_PATH=/root/ns/ns-allinone-2.29/otcl-l.12:/root/ns/ns- 
allinone-2.29/lib:$LD_L1BRARY_PATH 

TCL_LlBRARY=/root/ns/ns-allinone-2.29/tcl8.4.13/library:$TCL_L1BRARY 

The echo command in each case (i.e. $PATH, $LD_LIBRARY_PATH and 
$TCL_LIBRARY) will return the PATH variable that contains a list of 
previously included pathnames that is colon-delimited. 

5. Finally, to verify that ns2 has been successfully installed, enter “which ns” 
which will return /root/ns/ns-allinaone-2.29/bin/ns and “ns” which will return 
the ns command prompt “%” (enter “exit” on the prompt to exit ns). NS2 
can then be validate at the ns-2.29 directory with “./validate” command. 
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APPENDIX B - MOVEMENT PATTERN SCRIPT 


The script below is modified from a sample script provided by Matthias 
Budde in the NS forum, customized to our computed data. This script essentially 
parses the numerous data generated by the node movement computation using 
the Tcish command. Data points are extracted and arranged in the required 
format of the movement file. The computed movement data have to be arranged 
in anti-chronological order for subsequent computation of GOD object. 


### SCRIPT TO PARSE DATA INPUT AND GENERATE MOVEMENT EVENT FOR NS-2 
### Matthias Budde 2006, edited by Lim, Kwang Yong 

set infilename "./Nodemove2.txt" 
set outfilename "./oceanmovement2.sen" 

set infile [open $infilename ] 
set outfile [open $outfilename w] 

#Procedure to calculate seconds from time 
proc gettime [hrs mins} [ 

puts -nonewline "Transforming time $hrs:$mins to seconds: " 
set time [expr ($hrs * 3600) + ($mins * 60)] 
puts "$time" 
return $time 

} 

#Main 
puts "" 

puts "Parsing file \"$infilenameX"" 
puts "" 

while [ [ gets $infile line ] !=-!}[ 

# This regular expression looks for a line formatted like 
#"N:N N.N N.N" with n being any amount of digits from 
#0 to 9 and saving them to the variables a to d 

if [[regexp [([0-9]+):([0-9]+)["0-9]+([-0-9]+.[0-9]+)["0- 
9] + ([-0-9]+\. [0-9]+) } $line z a b c d] } [ 

set newtime [gettime $a $b] 
set newx $c 
set newy $d 
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if {$newtime ==0} { 

puts "Setting initial Position for Node $node" 
puts $outfile "$node set X_ $newx" 
puts $outfile "$node set Y_ $newy" 
puts $outfile "$node set Z_ 0.0" 

} 

set oldx $newx 
set oldy $newy 

# in the elseif, the node ID is changed if the line doesn't look 
like above but has the Word "Node " followed by a number. Also the 
time is reset to 0 

} elseif {[regexp {Node *{[0-9]+)} $line z a]} { 

set nodelD [expr $a - 1] 
puts "Setting Node ID to $nodeID" 
set node "\$node_($nodeID)" 
set newtime 0 

# in the else, if the line looks any other than the two above, it's 
ignored 

} else { 

# do nothing 

} 

} 

# This while statement reads the inputfile line per line 
set infile [open $infilename ] 

while { [ gets $infile line ] !=-!}{ 

# This regular expression looks for a line formatted like 
#"N:N N.N N.N" with n being any amount of digits from 
#0 to 9 and saving them to the variables a to d 

if {[regexp {([0-9]+):([0-9]+)["0-9]+([0-9]+\.[0-9]+)["0- 
9]+([0-9]+\.[0-9]+)["0-9]+(.I[0-9]+\.[0-9]+)} $line z a b c d e ]} { 

set newtime [gettime $a $b] 
set newx $c 
set newy $d 

if {$newtime >0} { 

set speed $e 

puts $outfile "\$ns_ at $newtime.O \"$node setdest 
$newx $newy $speed\"" 

} 
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# in the elseif, the node ID is changed if the line doesn't look 
like above but has the Word "Node " followed by a number. Also the 
time is reset to 0 

} elseif {[regexp {Node *{[0-9]+)} $line z a]} { 

set nodelD [expr $a - 1] 
puts "Setting Node ID to $nodeID" 
set node "\$node_($nodeID)" 
set newtime 0 

# in the else, if the line looks any other than the two above, it's 
ignored 

} else { 

# do nothing 

} 

} 

puts "" 

puts "DONE. Output has been written to \"$outfilename\". " 
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APPENDIX C - COMMUNICATION PATTERN SCRIPT 


The traffic connection pattern script is modified from a modification 
(Vaddina Prakash Rao) of the original constant bit rate generation script file by 
University of Southern California that is specifically designed for a star topology. 
The script is modified to generate traffic at an interval of 10 minutes which 
coincide with node movements. Nodes will be randomly selected to transmit data 
to the PAN coordinator. 


#The copyright for the original script lies with the following author. 
#Copyright (c) 1999 by the University of Southern California 
#A11 rights reserved. 

#Previous modified by Vaddina Prakash Rao 

#Modified by: 

#Lim Kwang Yong 

#Traffic source generator from CMU's mobile code. 

#Program to generate random traffic sources from nodes to coordinator. 

# Traffic is generated every ten minutes customized to ocean node movement. 

# =========================================================================== 

# Default Script Options, following default values are used when not provided 

# =========================================================================== 


set 

opt(nn) 

0 

;# 

Number of Nodes 

set 

opt(seed) 

0.0 

;# 

Random number generator seed value 

set 

opt(me) 

0 

;# 

Number of sources 

set 

opt(pktsize) 

70 

;# 

Packet size 

set 

opt(rate) 

0 

;# 

Datarate 

set 

opt(interval) 

0.0 

;# 

inverse of rate 

set 

opt(type) 

IT IT 

;# 

Traffic type 

set 

opt(starttime) 

20.0 

;# 

Traffic start time (need WPAN to 

establish) 




set 

opt(endtime) 

86400.0 

;# 

Traffic end time (1 day) 

set 

opt(timegap) 

30.0 

;# 

Default traffic gap time 


# 


set opt(outfilename) "./cbr/trafficpattern.traff" 
set opt(outfile) [open $opt(outfilename) w] 
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#================================================ 

# Procedure telling users the optional parameters 
#================================================ 

proc usage {} { 

global argvO 

puts "\nusage: $argvO \[-type cbr|tcp\] \[-nn nodesX] \[-seed seedX] 
X[-me connectionsX] X[-rate rateX] X[-starttime stX] X[-endtime etX] X[- 
timegap tgXlXn" 

} 

#===================================== 

# Procedure to get optional parameters 
#===================================== 

proc getopt [arge argv} [ 

global opt 

lappend optlist nn seed me rate type starttime timegap 

for [set i 0} [$i < $argc} [incr 1} [ 

set arg [lindex $argv $1] 

if [[string range $arg 0 0] != continue 

set name [string range $arg 1 end] 

set opt($name) [lindex $argv [expr $i+l]] 



#============== 

# CBR Procedure 
#============== 

proc create-cbr-connection [ sre dst stime } [ 

global rng cbr_cnt opt 

puts $opt (outfile) "#Xn# $src connecting to $dst at time $stimeXn#" 
puts $opt(outfile) "set udp_{$cbr_cnt) X[new Agent/UDPX]" 
puts $opt (outfile) "X$ns_ attach-agent X$node_($src) 
X$udp_($cbr_cnt)" 

puts $opt(outfile) "set null_($cbr_cnt) X[new Agent/NullX]" 
puts $opt (outfile) "X$ns_ attach-agent X$node_($dst) 
X$null_($cbr_cnt)" 

puts $opt (outfile) "set cbr_($cbr_cnt) X[new 
Application/Traffic/CBRX]" 

puts $opt (outfile) "X$cbr_($cbr_cnt) set packetSize_ $opt (pktsize)" 

puts $opt (outfile) "X$cbr_($cbr_cnt) set interval_ $opt(interval)" 

puts $opt (outfile) "X$cbr_($cbr_cnt) set random_ 1" 

puts $opt (outfile) "X$cbr_($cbr_cnt) set maxpkts_ 10000" 

puts $opt(outfile) "X$cbr_($cbr_cnt) attach-agent X$udp_($cbr_cnt)" 

puts $opt (outfile) "X$ns_ connect X$udp_($cbr_cnt) 

X$null_($cbr_cnt)" 

puts $opt (outfile) "X$ns_ at $stime X"X$cbr_($cbr_cnt) startX"" 
incr cbr_cnt 

} 
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#============== 

# TCP Procedure 
#============== 

proc create-tcp-connection { src dst stime } { 

global rng cbr_cnt opt 

puts $opt (outfile) "#\n# $src connecting to $dst at time $stime\n#" 
puts $opt (outfile) "set tcp_($cbr_cnt) \[\$ns_ create-connection \ 
TCP \$node_{$src) TCPSink \$node_{$dst) 0\]"; 
puts $opt (outfile) "\$tcp_($cbr_cnt) set window_ 32" 
puts $opt (outfile) "\$tcp_($cbr_cnt) set packetSize_ $opt (pktsize)" 
puts $opt (outfile) "set ftp_($cbr_cnt) \[\$tcp_($cbr_cnt) attach- 
source FTP\]" 

puts $opt (outfile) "\$ns_ at $stime \"\$ftp_($cbr_cnt) startX"" 
incr cbr_cnt 

} 

#============= 

# Main Program 
#============= 

getopt $argc $argv 

if { $opt(type) == "" } { 

usage 
exit 

} elseif { $opt(type) == "cbr" } { 

if { $opt(nn) == 0 I I $opt(seed) ==0.0 | | $opt(me) == 0 | | $opt(rate) 
== 0 } { 

usage 

exit 

} 

set opt(interval) [expr 1.0 / $opt(rate)] 
if { $opt(interval) <=0.0 } { 

puts "\ninvalid sending rate $opt(rate)\n" 
exit 

} 

} 

puts "#\n# nodes: $opt(nn), max conn: $opt(me), send rate: $opt(interval), 
seed: $opt(seed)\n#" 

# Loop to transmit traffic within defined interval 
set looptime [expr $opt(endtime)/600] 

for {set k 1} {$k < $looptime} {incr k} { 


set rng [new RNG] 
$rng seed $opt{seed) 
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set u [new RandomVariable/Uniform] 

$u set min_ 0 
$u set inax_ $opt (nn) 

$u use-rng $rng 

set cbr_cnt 0 
set src_cnt 0 
set flag 0 

set loopcount $opt(nn) 

# Loop till the defined connenction has completed, generated scr number 

for {set 10} ($1 < $loopcount } (incr 1} { 

while {1} { 

set X [$u value] 
set X [expr $x/0.01] 
if {$x < $opt(nn)} { 

set src [expr round($x)] 
break 

} 

} 

if { $src >= $opt(nn) } { 
set src [expr $opt(nn)-l] 

} 

# Add the generated source to the list unless we already had the 
source before 

if {[array size sources] == 0} { 
set sources(0) $src 
} else { 

# Comparing each source in list to currently generated source to see 
if match 

for {set p 0} {$p < [array size sources]} {incr p 1} { 
if {$src == $sources($p)} { 
set flag 1 
break 

} 

} 

if {$src == 12} { 
set flag 1 

} 

# If there is a match, break from the current loop (discard the source) 

if {$flag == 1} { 
set flag 0 
incr loopcount 1 
continue 
} else { 

set size [array size sources] 
set sources ($size) $src 

} 

} 
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# Destination to be node-12 (PAN coordinator). 
set dst 12 

if { $opt(type) == "cbr" } { 

incr src_cnt 1 

create-cbr-connection $src $dst $opt(starttime) 

} else { 

create-tcp-connection $src $dst $opt(starttime) 

} 

if { $src_cnt == $opt(me) } { 

# You have created the required number of sources. So break now !! 

break 
} else { 

# If required number of sources have not been reached yet. 

set temp $loopcount 
incr temp -1 
if {$i == $temp} { 
incr loopcount 1 

} 

} 

# Tx each node at an interval 

set opt(starttime) [expr $opt(starttime)+$opt(timegap)] 

} 

# Tx in the next cycle and reset source array 
set opt(starttime) [expr $k*600] 
unset sources 

} 

puts $opt (outfile) "#\n#Total sources: $src_cnt\n#" 
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APPENDIX D - SAMPLE TCL SCRIPT 


The sample TCL script provided is the configuration file for simulation. 
Some of the parameters are hard coded which needs to be varied and monitored 
to execute different sets of experimentations. 



############################################# 


# 

802.15.4 (beacon enabled) 


# 


# 

Copyright (c) 2003 Samsung/CUNY 

# 


# - - 


- - 

-# 


# 

Prepared by Jianliang Zheng 


# 


# 

(zheng@ee.ccny.cuny.edu) 


# 


# 



# 


# 

Modified By: him Kwang Yong 


# 


# 

Naval Post-Graduate School 


# 


############################################# 

# Ocean movement 

scenario 25 nodes, 10m apart from 

adjacent nodes 

■ff 

# Set parameters 

regarding channel, medium, MAC 

protocol, routing 

protocol, energy 

model ... 



#- 

set 

val(chan) 

Channel/WirelessChannel 

;# 

Channel Type 

set 

val (prop) 

Propagation/TwoRayGround 

;# 

radio-propagation model 

set 

val (netlf) 

Phy/WirelessPhy/802_15_4 



set 

val(mac) 

Mac/802_15_4 



set 

val(Ifq) 

Queue/DropXail/PrlQueue 

;# 

interface queue type 

set 

val (11) 

LL 

;# 

link layer type 

set 

val (ant) 

Antenna/OmnlAntenna 

;# 

antenna model 

set 

val(Ifqlen) 

150 

;# 

packet in ifq 

set 

val(nn) 

25 

;# 

number of mobilenodes 

set 

val(rp) 

AODV 

;# 

routing protocol 

set 

val(x) 

4500 

;# 

X dimension topography 

set 

val(y) 

4500 

;# 

y dimension topography 

set 

val(tr) 

ocean_move_25_3hr.tr 

;# 

trace file 

set 

val(nam) 

ocean_move_25_3hr.nam 

;# 

nam trace file 

set 

val(move) 

oceanmove3hr.sen 

;# 

movement scenario 

set 

val(cp) 

traffic_3hr_pattern.traff 

;# 

connection traffic 

#set val(Energy) 

EnergyModel 

;# 

Evaluate energy 

set 

val(starttime) 5 


f 

set 

val(appTimel) 

[expr $val(starttime)+20 

] 

f 

set 

appTime2 

[expr $val(appTimel)+0.3 

] 

f 

set 

stopTime 

10800 


f 
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#read command line arguments 
#=========================== 

proc getCmdArgu {argc argv} { 
global val 

for {set 1 0} {$1 < $argc} {incr 1} { 

set arg [lindex $argv $1] 

if {[string range $arg 0 0] != continue 

set name [string range $arg 1 end] 

set val($name) [lindex $argv [expr $i+l]] 



getCmdArgu $argc $argv 

#========================================= 

# Define antenna at node centre of ht 0.1m 
#========================================= 

Antenna/OmniAntenna set X_ 0 
Antenna/OmniAntenna set Y_ 0 
Antenna/OmniAntenna set Z_ 0.1 
Antenna/OmniAntenna set Gt_ 1.0 
Antenna/OmniAntenna set Gr_ 1.0 

#============================ 

# Initialize Global Variables 
#============================ 

set ns_ [new Simulator] 

#========================================================= 

# Create trace object for ns and nam, use new trace format 
#========================================================= 

set tracefd [open ./$val{tr) w] 

$ns_ trace-all $tracefd 

# Statement indicating to simulator about NAM. 

set namtrace [open ./$val{nam) w] 

$ns_ namtrace-all-wireless $namtrace $val(x) $val(y) 

#$ns_ use-newtrace 

#======================================================================== 

# Inform nam that this is a trace file for wpan (special handling needed) 
#======================================================================== 

$ns_ puts-nam-traceall [# nam4wpan #} 

Mac/802_15_4 wpanCmd verbose on 

Mac/802_15_4 wpanNam namStatus on ;# default = off (should be 

turned on before other 'wpanNam' 
commands can work) 

Mac/802_15_4 wpanNam ColFlashClr black ;# default = gold 
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#========================= 

# For model 'TwoRayGround' 

#========================= 

Phy/WirelessPhy set CSThresh_ 3.981e-13; 

Phy/WirelessPhy set RXThresh_ 3.981e-13; 

Phy/WirelessPhy set CPThresh_ 10; 

Phy/WirelessPhy set freq_ 2.4e+9; 

Phy/WirelessPhy set L_ 1.0; 

Phy/WirelessPhy set pt_ 0.001; 

#==================================== 

# set up and define topography object 
#==================================== 

set topo [new Topography] 

$topo load_flatgrid $val(x) $val(y) 

#========== 

#Create God 
#========== 

set god_ [create-god $val(nn)] 
set chan_l_ [new $val(chan)] 

#=============== 

# configure node 
#=============== 

$ns_ node-config -adhocRouting $val(rp) \ 

-llType $val(ll) \ 

-macType $val(mac) \ 

-ifqType $val(ifq) \ 

-ifqLen $val(ifqlen) \ 

-antType $val(ant) \ 

-propType $val(prop) \ 

-phyType $val(netif) \ 

-topolnstance $topo \ 

-agentTrace ON \ 

-routerTrace ON \ 

-macTrace ON \ 

-movementXrace ON\ 

-channel $chan_l_ 
#========================== 

# Parameter req. only when energy logging 
#======================================== 

#-energyModel EnergyModel \ 

#-initialEnergy 13000 \ 

#-rxPower 0.0648 \ 

#-txPower 0.0744 \ 

#-idlePower 0.00000552 \ 


#carrier sensing threshold 
#receiver threshold 
#capture threshold 
#Operating Freq 
#System loss factor 
#Tx power 
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#=============================================== 

# Creates specified node and attached to channel 
#=============================================== 

for {set i 0} {$i < $val(nn) } (incr i} { 

set node_($i) [$ns_ node] 

$node_($i) random-motion 0 ;# disable random motion 

} 

#========================= - 

# Define movement scenario 
#========================= 

puts "Loading movement pattern ..." 
source $val(move) 

#=============== 

# SSCS Interface 
#=============== 

$ns_ at 0.0 "$node_(12) NodeLabel \"PAN Coor\"" 

# Cmd used to start a new PAN with corresponding node as PAN coordinator 

# default <txBeacon=l> <beaconOrder=3> <SuperframeOrder=3> 

$ns_ at 0.0 "$node_(12) sscs startPANCoord 0" ;# startPANCoord 

# Cmd used to start a device 

# default <isFFD=l> <assoPermit=l> <txBeacon=0> <BO=3> <SO=3> 

$ns_ at 0.3 "$node_(7) sscs startCTDevice 1 1 1" 

$ns_ at 1.3 "$node_(13) sscs startCTDevice 1 1 1" 

$ns_ at 1.7 "$node_(17) sscs startCTDevice 1 1 1" 

$ns_ at 2.3 "$node_(ll) sscs startCTDevice 1 1 1" 

$ns_ at 3.3 "$node_(8) sscs startCTDevice 1 1 1" 

$ns_ at 3.5 "$node_(18) sscs startCTDevice 1 1 1" 

$ns_ at 3.6 "$node_(16) sscs startCTDevice 1 1 1" 

$ns_ at 3.8 "$node_(6) sscs startCTDevice 1 1 1" 

$ns_ at 4.3 "$node_(2) sscs startCTDevice 1 1 1" 

$ns_ at 4.5 "$node_(14) sscs startCTDevice 1 1 1" 

$ns_ at 4.8 "$node_(22) sscs startCTDevice 1 1 1" 

$ns_ at 5.1 "$node_(10) sscs startCTDevice 1 1 1" 

$ns_ at 5.6 "$node_(3) sscs startCTDevice 1 1 1" 

$ns_ at 5.8 "$node_(19) sscs startCTDevice 1 1 1" 

$ns_ at 6.0 "$node_(21) sscs startCTDevice 1 1 1" 

$ns_ at 6.3 "$node_(5) sscs startCTDevice 1 1 1" 

$ns_ at 6.8 "$node_(4) sscs startCTDevice 1 1 1" 

$ns_ at 7.0 "$node_(24) sscs startCTDevice 1 1 1" 

$ns_ at 7.3 "$node_(20) sscs startCTDevice 1 1 1" 

$ns_ at 7.7 "$node_(0) sscs startCTDevice 1 1 1" 
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$ns_ at 8.2 "$node_(l) sscs startCTDevice 1 1 1" 

$ns_ at 8.5 "$node_(9) sscs startCTDevice 1 1 1" 

$ns_ at 8.8 "$node_(23) sscs startCTDevice 1 1 1" 

$ns_ at 9.1 "$node_(15) sscs startCTDevice 1 1 1" 

#$ns_ at $appTime2 "$node_(12) sscs stopBeacon" 

Mac/802_15_4 wpanNam PlaybackRate 3ms 

$ns_ at $val(appTimel) "puts \"\nTransmitting data ...\n\"" 

#================================= 

# Setup traffic flow between nodes 
#================================= 

puts "Loading traffic pattern ..." 
source $val(cp) 

# Mac/802_15_4 wpanNam FlowClr [-p <packet_type_name>] [-s <src>] [-d 

<dst>] [-C <clrName>] 

Mac/802_15_4 wpanNam FlowClr -p AODV -c red 
Mac/802_15_4 wpanNam FlowClr -p ARP -c green 

Mac/802_15_4 wpanNam FlowClr -p MAC -c navy 

Mac/802_15_4 wpanNam FlowClr -p tcp -c blue 

Mac/802_15_4 wpanNam FlowClr -p ack -c cyan4 

#================================== 

# defines the node size (3) in nam 
#================================== 

for {set i 0} {$i < $val(nn)} (incr i} { 

$ns_ initial_node_pos $node_($i) 3 

} 

#==================================== 

# Tell nodes when the simulation ends 
#==================================== 

for (set i 0} {$i < $val(nn) } (incr i} { 

$ns_ at $stopTime "$node_($i) reset"; 

} 

$ns_ at $stopTime "stop" 

$ns_ at $stopTime "puts \"NS EXITING...\n\"" 

$ns_ at $stopTime "$ns_ halt" 


89 

















proc stop { } { 

global ns_ tracefd val(starttime) val env 
$ns_ flush-trace 
close $tracefd 
set hasDISPLAY 0 

foreach index [array names env] { 
puts "$index: $env($index)" 

if { ("$index" == "DISPLAY") && ("$env($index)" != "") } { 

set hasDISPLAY I 


if { ("$val(nam)" == "ocean_move_25_3hr.nam") && ("$hasDISPLAY" == "I") 

} { 

exec nam ocean_move_25_3hr.nam 



puts "\nStarting Simulation... 

$ns_ run 

#============== 

# End of script 
#============== 
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APPENDIX E - SAMPLE TRACE FILE FORMAT 


s 

0.000640000 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff c 0] 





s 

0.140160000 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff c 0] 





s 

0.280320000 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff c 0] 





s 

0.300960000 

_7_ 

MAC 

-0 

CM7 8 

[0 ffffffff 7 0] 





s 

0.564960000 

_7_ 

MAC 

-0 

CM7 8 

[0 ffffffff 7 0] 





s 

0.828640000 

_7_ 

MAC 

-0 

CM7 8 

[0 ffffffff 7 0] 





s 

1.301920000 

_13_ 

MAC 

-0 

CM7 

8 [0 ffffffff d 0] 





r 

1.302368026 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff d 0] 





s 

1.304928026 

_12_ 

MAC 

-0 

BCN 

11 [Ode 0] 





s 

1.564000000 

_13_ 

MAC 

-0 

CM7 

8 [0 ffffffff d 0] 





s 

1.702240000 

_17_ 

MAC 

-0 

CM7 

8 [0 ffffffff 11 0] 





r 

1.702688033 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff 11 0] 





s 

1.703968033 

_12_ 

MAC 

-0 

BCN 

11 [0 11 c 0] 





s 

1.827360000 

_13_ 

MAC 

-0 

CM7 

8 [0 ffffffff d 0] 





r 

1.827808042 

_7_ 

MAC 

-0 

CM7 8 

[0 ffffffff d 0] 





s 

1.964640000 

_17_ 

MAC 

-0 

CM7 

8 [0 ffffffff 11 0] 





s 

2.091040000 

_13_ 

MAC 

-0 

CMl 

17 [0 c d 0] 





r 

2.091776026 

_12_ 

MAC 

-0 

CMl 

17 [0 c d 0] 





s 

2.091968026 

_12_ 

MAC 

-0 

ACK 

5 [0 d c 0] 





r 

2.092320052 

_13_ 

MAC 

-0 

ACK 

5 [0 d c 0] 





s 

2.092960000 

_7_ 

MAC 

-0 

CM7 8 

[0 ffffffff 7 0] 





r 

2.093408033 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff 7 0] 





s 

2.095008033 

_12_ 

MAC 

-0 

BCN 

11 [07c 0] 





s 

2.227680000 

_17_ 

MAC 

-0 

CM7 

8 [0 ffffffff 11 0] 





s 

2.301920000 

_ 11 _ 

MAC 

-0 

CM7 

8 [0 ffffffff b 0] 





r 

2.302368026 

_12_ 

MAC 

-0 

CM7 

8 [0 ffffffff b 0] 





D 

2.302368043 

_7_ 

MAC 

APS 0 

CM7 8 

[0 ffffffff b 0] 





s 

2.303648026 

_12_ 

MAC 

-0 

BCN 

11 [0 b c 0] 





s 

2.355680000 

_7_ 

MAC 

-0 

CM7 8 

[0 ffffffff 7 0] 





s 

2.491680000 

_17_ 

MAC 

-0 

CMl 

17 [0 c 11 0] 





r 

2.492416033 

_12_ 

MAC 

-0 

CMl 

17 [0 c 11 0] 





s 

2.492608033 

_12_ 

MAC 

-0 

ACK 

5 [0 11 c 0] 





r 

2.492960067 

_17_ 

MAC 

-0 

ACK 

5 [0 11 c 0] 





s 

2.565280000 

_ 11 _ 

MAC 

-0 

CM7 

8 [0 ffffffff b 0] 





D 

2.565728043 

_7_ 

MAC 

APS 0 

CM7 8 

[0 ffffffff b 0] 





D 

27.267808849 

_ 2 _ 

MAC 

coo 0 

BCN 

12 [0 ffffffff 13 0] 





D 

27.267808860 

_5_ 

MAC 

coo 0 

BCN 

12 [0 ffffffff 13 0] 





D 

27.267808863 

_ 1 _ 

MAC 

coo 0 

BCN 

12 [0 ffffffff 13 0] 





D 

27.267808880 

_ 0 _ 

MAC 

coo 0 

BCN 

12 [0 ffffffff 13 0] 





s 

27.268180039 

_18 

_ ACT 

— 

2 cbr 

20 [0 0 0 0] - 

[18:0 

12:0 

32 

0] 

[2] 0 1 










r 

27.268180039 

_18 

_ RTR 

— 

2 cbr 

20 [0 0 0 0] - 

[18:0 

12:0 

32 

0] 

[2] 0 1 










s 

27.268180039 

_18 

_ RTR 

— 

2 cbr 

40 [000 0] - 

[18:0 

12:0 

30 

12] 

[2] 0 1 
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APPENDIX F - SAMPLE AWK SCRIPTS 


This script is modified from the many example scripts provided in the NS2 
forum to parse the data from in the trace file format. 


# Lim Kwang Yong 

# Usage: awk -f <awk_script.awk> <trace_file.tr> 

# Parse a ns2 wireless trace file and generate performance metrics 
BEGIN { 

droppedRTGpackets=0; 
droppedbRTGbytes=0; 
droppedMACbytes=0; 
droppedMACpackets=0; 
droppedbDATAbytes=0; 
droppedbDATApackets=0; 
droppedIFQpackets=0; 
droppedLQIbytes=0; 
droppedLQIpackets=0 ; 
droppedIFQbytes=0; 
totalDROPPEDpackets=0; 
totalDROPPEDbytes=0 ; 
dataSent=0; 
dataRecd=0 ; 
sentData=0; 
sentDataBytes=0; 

TotalsentData=0; 

TotalsentDataBytes=0 ; 
recdData=0; 
recdDataBytes=0 ; 
sends=0; 
recvs=0; 

RTGbytes=0; 
fwdData=0; 
fwdDataBytes=0; 
fwdRtg=0; 
fwdRtgBytes=0 ; 
fwdMac=0; 
fwdMacBytes=0 ; 

highest_packet_id=0; #used to compare with the packet id 

highest_time=0 

sum=0; 

RTG=0; 

MACDATA=0; 

MACRTG=0; 

} 
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{ 

#============================= 

# Check for the highest packet ID & time 
#============================= 

action = $1; 
time = $2; 
node_id = $3 

if ($7 =="cbr"){packet_id = $6;}; 

if ( packet_id > highest_packet_id ) {highest_packet_id = packet_id;}; 
if ( time > highest_time) {highest_time = time} 

#============ 

# Calculate delay 
#============ 

if ( start_time[packet_id] == 0 ) {start_time[packet_id] = time;}; 

if ( action != "D" ) { 

if ( action == "r" ) {end_time[packet_id] = time;}; 

} 

else {end_time[packet_id] = -1;}; 

#=========== 

#Calculate PDF 
#=========== 

if (($1 == "s") && ($7 == "cbr") && ($4 =="AGT")) { 

sends+t; 

dataSent=dataSent+$8; 

} 

if ( ( $1 == "r") && ( $7 == "cbr" ) && ( $4 == "ACT" ) ) { 

recvs+t; 

dataRecd=dataRecd+$8; 

} 

#=============== 

# Calculate RTG load 
#=============== 

if ((( $1 == "s") II ($l=="f") ) && ( $7 == "cbr" ) && ( $4 =="RTR" )) { 

sentData+t; 

sentDataBytes=sentDataBytes+$8; 

} 

if ( ( $1 == "r") && ( $7 == "cbr" ) && ( $4 == "RTR" ) ) { 

recdData+t; 

recdDataBytes=recdDataBytes+$8; 

} 

#============== 

# RTG protocol pkts 
#============== 

if ( (($l=="f") II ($l=="s") ) && ($4 == "RTR") && ($7 =="AODV" ) ) { 

RTG++; 

RTGbytes=RTGbytes+$8; 

} 
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#============ 

# MAC data pkts 
#============ 

if ( (($l=="f") II ($l=="s") ) && ($4 == "MAC") && ($7 =="cbr" ) ) { 

MACDATA++; 

} 

#============= 

# MAC RTG pkts 
#============= 

if ( (($l=="f") II ($l=="s") ) && ($4 == "MAC") && ($7 =="AODV" ) ) { 

MACRTG++; 

} 

#============== 

# Dropped data pkts 
#============== 

if ( ($1 == "D") && ($7 =="cbr") && ( $4 == "RTR" )){ 

droppedDATAbytes=droppedDATAbytes+$8 ; 
droppedDATApackets=droppedDATApackets+l; 

} 

#=============== 

# Dropped MAC pkts 
#=============== 

if ( ($1 == "D") && ($4 == "MAC" )){ 

droppedMACbytes=droppedMACbytes+$8 ; 
droppedMACpackets=droppedMACpackets+l; 

} 

#=============== 

# Dropped RTG pkts 
#=============== 

if ( ($1 == "D") && ($4 == "RTR" ) && ($8 == "AODV")){ 

droppedRTGbytes=droppedRTGbytes+$8 ; 
droppedRTGpackets=droppedRTGpackets+l; 

} 

#============== 

# Dropped IFQ pkts 
#============== 

if (($1 == "D") && ($4 == "IFQ")){ 

droppedIFQbytes=droppedIFQbytes+$8 ; 
droppedIFQpackets=droppedIFQpackets+l; 

} 

#============== 

# Dropped LQI pkts 
#============== 

if (($1 == "D") && ($4 == "IFQ")){ 

droppedLQIbytes=droppedLQIbytes+$8 ; 
droppedLQIpackets=droppedLQIpackets+l; 

} 
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#============== 

# Total dropped pkts 
#============== 

if ($1 == "D") { 

totalDROPPEDpackets+i; 

totalDR0PPEDbytes=totalDR0PPEDbytes+$8 

} 

#============== 

# Forward data pkts 
#============== 

if { ($1 == "f") && ($7 == "cbr") && ($4 == "RTR" ) ) { 

fwdData++; 

fwdDataBytes=fwdDataBytes+$8; 

} 

#============== 

# Forward RTG pkts 
#============== 

if { { $1 == "f") && ($7 == "AODV") && ($4 == "RTR") ) { 

fwdRtg++; 

fwdRtgBytes=fwdRtgBytes+$8; 

} 

#=============== 

# Forward MAC pkts 
#=============== 

if { { $1 == "f") && ($4 == "MAC" ) ) { 

fwdMac++; 

fwdMacBytes=fwdMacBytes+$8; 

} 

#============== 

# Total forward pkts 
#============== 

if { $1 == "f") { 

fwdpackets++; 
fwdBytes=fwdBytes+$8; 

} 

if ($1 == "D") { 

droppingnodes= $3; 

} 

} 

END { 

for { packet_id = 0; packet_id <= highest_packet_id; packet_id++ ) { 

start = start_time[packet_id]; 
end = end_time[packet_id]; 
packet_duration = end - start; 
if (start < end) sum= packet_duration+sum; 

} 
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#========== 

# Show results 
#========== 


printf{"\n .Data parsed from trace file with 25 

NODES.\n\n") >> "performance.txt"; 

printfC 1. No. of CBR Packets sent = %d PACKETS \n ", sends) >> 
"performance.txt"; 

printfC 2. No. of CBR Bytes sent = %d BYTES \n", dataSent) >> 
"performance.txt"; 

printfC 3. No. of CBR Packets received = %d PACKETS \n", recvs) >> 
"performance.txt"; 

printfC 4 . No. of CBR Bytes received = %d BYTES \n", dataRecd) >> 
"performance.txt"; 

printfC \n .Routing details.\n\n") >> 

"performance.txt"; 

printfC 5. No. of routing packets = %d PACKETS \n",RTG) >> 

"performance.txt"; 

printfC 6. No. of routing bytes = %d BYTES \n", RTGbytes) >> 

"performance.txt"; 

printfC \n .MAC details.\n\n") >> "performance.txt"; 

printfC 3. No. of MAC packets for data sent = %d PACKETS \n", MACDATA) 

>> "performance.txt"; 

printfC 8. No. of MAC packets for Rtg sent = %d PACKETS \n", MACRTG) >> 
"performance.txt"; 

printfC 9. Total No. of MAC Packets sent = %d PACKETS \n", 
MACRTG+MACDATA) >> "performance.txt"; 

printfC \n .Forwarding details.\n\n") >> 

"performance.txt"; 

printfC 10. No. of DATA Packets Fwd = %d PACKETS \n", fwdData) >> 
"performance.txt"; 

printfC 11. No. of DATA Bytes Fwd = %d BYTES \n", fwddataBytes) >> 
"performance.txt"; 

printfC 12. No. of RTG Packets Fwd = %d PACKETS \n", fwdRtg) >> 
"performance.txt"; 

printfC 13. No. of RTG Bytes Fwd = %d BYTES \n", fwdRtgBytes) >> 
"performance.txt"; 

printfC 14 . No. of MAC Packets Fwd = %d PACKETS \n", fwdMac) >> 
"performance.txt"; 

printfC 15. No. of MAC Bytes Fwd = %d BYTES \n", fwdMacBytes) >> 
"performance.txt"; 

printfC 16. Total No. of Fwd packets = %d PACKETS \n", fwdpackets) >> 
"performance.txt"; 

printfC 13. Total No. of Fwd Bytes = %d BYTES \n", fwdBytes) >> 
"performance.txt"; 

printfC \n .Dropping details.\n\n") >> 

"performance.txt"; 

printfC 18. Dropping nodes are %d nodes \n", droppingnodes) >> 
"performance.txt"; 

printfC 19. No. of dropped data (packets) = %d PACKETS 
\n",droppedDATApackets) >> "performance.txt"; 

printfC 20. No. of dropped data (bytes) = %d BYTES \n",droppedDATAbytes) 
>> "performance.txt"; 
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printfC 21. No. of dropped MAC (packets) = %d PACKETS 
\n",droppedMACpackets) >> "performance.txt"; 

printfC 22. No. of dropped MAC (bytes) = %d BYTES \n",droppedMACAbytes) 
>> "performance.txt"; 

printfC 23. No. of dropped RTG (packets) = %d PACKETS 
\n",droppedRTGpackets) >> "performance.txt"; 

printfC 24. No. of dropped RTG (bytes) = %d BYTES \n",droppedRTGbytes) 

>> "performance.txt"; 

printfC 25. No. of dropped IFQ (Packets) = %d PACKETS 
\n",droppedIFQpackets) >> "performance.txt"; 

printfC 26. No. of dropped IFQ (bytes) = %d BYTES \n",droppedIFQbytes) 

>> "performance.txt"; 

printfC 27. No. of dropped LQI (Packets) = %d PACKETS 
\n",droppedLQIpackets) >> "performance.txt"; 

printfC 28. No. of dropped LQI (bytes) = %d BYTES \n",droppedIFQbytes) 

>> "performance.txt"; 

printfC 29. Total No. of Dropped (packets) = %d PACKETS 
\n\n",totalDROPPEDpackets) >> "performance.txt"; 
printfC 30. Total No. of Dropped (Bytes)) = %d BYTES 
\n\n",totalDROPPEDbytes) >> "performance.txt"; 

printf("\n .PERFQRMANCE METRICES .\n\n") 

>> "performance.txt"; 

printfC 1. Packet Delivery Ratio (PDR %) = %f %\n", (recvs/sends) *100) 

>> "performance.txt"; 

printfC 2. Average Network delay = %f \n", sum/highest_packet_id) >> 
"performance.txt"; 

printfC 3. Network Throughput = %f \n", (dataRecd/highest_time)/25) >> 
"performance.txt"; 

printfC 4. Normalised routing load (Packets %) = %f %\n", 

(RTG/sentData)*100) >> "performance.txt"; 

printfC 5. Normalised routing load (Bytes %) = %f %\n", 
(RTGbytes/sentDataBytes)*100) >> "performance.txt"; 

printfC 6. Routing QVERHEAD (Packets %) = %f %\n", (MACRTG/MACDATA)*100) 
>> "performance.txt"; 

printfC 7. Qptimal Hop Count = %f \n\n", MACDATA/sends) >> 

"performance.txt"; 
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APPENDIX G - NODES POSITION AT VARIOUS TIME INTERVAL 
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